Le probleme commence comme ca. Le deuxieme probleme
qui survient a la requete d'apres: le client
envois bien une requete GET sur un fichier
javascript mais aucun contenu ne reviens
sur (je ne sais pas si ca viens d'apache ou d'IIS)
1) Premiere remarque.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
La RFC précise qu'un code retour
doit etre suivie d'une note. Exemple:
304 Not Modified.
2) Deuxieme remarque
Cette même RFC précise bien qu'un code 304 n'a pas
a avoir de Body. Hors on voit bien dans les headers
qu'on a un Content-Length: 16. J'espere qu'il n'y
a pas une bidouille a la fois dans Internet Explorer
et Sharepoint pour quand même prendre en considération
le body d'un code 304. En tout cas, le reverse proxy
apache drop le body puisqu'il respecte le RFC sur ce
coup la.
Note: j'ai déjà browser KB microsoft & marc mailing list
mais rien ... vide total sur ce comportement.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
EROL MVP SPS - Club SPS
Bonjour,
Sans la version de SPS cela me semble délicat, je sais qu'il existe un doc. sur le reverse proxy http://www.microsoft.com/technet/prodtechnol/sppt/wss/revproxy.mspx
Cdlt
-- Prochaine Réunion du Club SharePoint FRANCE Le 7 Février 2006 à PARIS. Elle aura lieu : Microsoft Paris 148 rue de l'Université 75007 Paris Pour vous inscrire gratuitement au club SPS, cliquer ici : http://inscrits.clubsps.org/ . -- EROL http://www.clubsps.org http://sharepointerol.blogspot.com/
"bla" a écrit dans le message de news: 43e39cbc$0$390$
Bonsoir le monde,
Voila ce que je ne sais pas : - version Sharepoint - version IIS (6, mais sans plus) - s'il y a des SP d'installé
Voila ce que j'ai : - un sniff des headers (pas de sniff body)
Voila ce que je veux faire - client -> reverse proxy (apache/https) -> sharepoint/https
Comme d'habitude quand on met un reverse proxy devant des applis web microsoft: c'est plein de surprise ...
Le probleme commence comme ca. Le deuxieme probleme qui survient a la requete d'apres: le client envois bien une requete GET sur un fichier javascript mais aucun contenu ne reviens sur (je ne sais pas si ca viens d'apache ou d'IIS)
1) Premiere remarque. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html La RFC précise qu'un code retour doit etre suivie d'une note. Exemple: 304 Not Modified.
2) Deuxieme remarque Cette même RFC précise bien qu'un code 304 n'a pas a avoir de Body. Hors on voit bien dans les headers qu'on a un Content-Length: 16. J'espere qu'il n'y a pas une bidouille a la fois dans Internet Explorer et Sharepoint pour quand même prendre en considération le body d'un code 304. En tout cas, le reverse proxy apache drop le body puisqu'il respecte le RFC sur ce coup la.
Note: j'ai déjà browser KB microsoft & marc mailing list mais rien ... vide total sur ce comportement.
Question: quelqu'un a une idée ?
En vous remerciant par avance...
Bonjour,
Sans la version de SPS cela me semble délicat, je sais qu'il existe un doc.
sur le reverse proxy
http://www.microsoft.com/technet/prodtechnol/sppt/wss/revproxy.mspx
Cdlt
--
Prochaine Réunion du Club SharePoint FRANCE
Le 7 Février 2006 à PARIS.
Elle aura lieu :
Microsoft Paris
148 rue de l'Université
75007 Paris
Pour vous inscrire gratuitement au club SPS,
cliquer ici : http://inscrits.clubsps.org/ .
--
EROL
http://www.clubsps.org
http://sharepointerol.blogspot.com/
"bla" <youp@tralala.com> a écrit dans le message de news:
43e39cbc$0$390$636a55ce@news.free.fr...
Bonsoir le monde,
Voila ce que je ne sais pas :
- version Sharepoint
- version IIS (6, mais sans plus)
- s'il y a des SP d'installé
Voila ce que j'ai :
- un sniff des headers (pas de sniff body)
Voila ce que je veux faire
- client -> reverse proxy (apache/https) -> sharepoint/https
Comme d'habitude quand on met un reverse proxy devant des applis
web microsoft: c'est plein de surprise ...
Le probleme commence comme ca. Le deuxieme probleme
qui survient a la requete d'apres: le client
envois bien une requete GET sur un fichier
javascript mais aucun contenu ne reviens
sur (je ne sais pas si ca viens d'apache ou d'IIS)
1) Premiere remarque.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
La RFC précise qu'un code retour
doit etre suivie d'une note. Exemple:
304 Not Modified.
2) Deuxieme remarque
Cette même RFC précise bien qu'un code 304 n'a pas
a avoir de Body. Hors on voit bien dans les headers
qu'on a un Content-Length: 16. J'espere qu'il n'y
a pas une bidouille a la fois dans Internet Explorer
et Sharepoint pour quand même prendre en considération
le body d'un code 304. En tout cas, le reverse proxy
apache drop le body puisqu'il respecte le RFC sur ce
coup la.
Note: j'ai déjà browser KB microsoft & marc mailing list
mais rien ... vide total sur ce comportement.
Sans la version de SPS cela me semble délicat, je sais qu'il existe un doc. sur le reverse proxy http://www.microsoft.com/technet/prodtechnol/sppt/wss/revproxy.mspx
Cdlt
-- Prochaine Réunion du Club SharePoint FRANCE Le 7 Février 2006 à PARIS. Elle aura lieu : Microsoft Paris 148 rue de l'Université 75007 Paris Pour vous inscrire gratuitement au club SPS, cliquer ici : http://inscrits.clubsps.org/ . -- EROL http://www.clubsps.org http://sharepointerol.blogspot.com/
"bla" a écrit dans le message de news: 43e39cbc$0$390$
Bonsoir le monde,
Voila ce que je ne sais pas : - version Sharepoint - version IIS (6, mais sans plus) - s'il y a des SP d'installé
Voila ce que j'ai : - un sniff des headers (pas de sniff body)
Voila ce que je veux faire - client -> reverse proxy (apache/https) -> sharepoint/https
Comme d'habitude quand on met un reverse proxy devant des applis web microsoft: c'est plein de surprise ...
Le probleme commence comme ca. Le deuxieme probleme qui survient a la requete d'apres: le client envois bien une requete GET sur un fichier javascript mais aucun contenu ne reviens sur (je ne sais pas si ca viens d'apache ou d'IIS)
1) Premiere remarque. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html La RFC précise qu'un code retour doit etre suivie d'une note. Exemple: 304 Not Modified.
2) Deuxieme remarque Cette même RFC précise bien qu'un code 304 n'a pas a avoir de Body. Hors on voit bien dans les headers qu'on a un Content-Length: 16. J'espere qu'il n'y a pas une bidouille a la fois dans Internet Explorer et Sharepoint pour quand même prendre en considération le body d'un code 304. En tout cas, le reverse proxy apache drop le body puisqu'il respecte le RFC sur ce coup la.
Note: j'ai déjà browser KB microsoft & marc mailing list mais rien ... vide total sur ce comportement.
Question: quelqu'un a une idée ?
En vous remerciant par avance...
bla
EROL MVP SPS - Club SPS wrote:
Bonjour,
Sans la version de SPS cela me semble délicat, je sais qu'il existe un doc. sur le reverse proxy http://www.microsoft.com/technet/prodtechnol/sppt/wss/revproxy.mspx
Cdlt
Oui, mais c'est une doc ISA server donc proprio microsoft, c'est sur que ca va marcher. ISA server corrige bcp de bugs émis par un backend IIS dans un contexte reverse proxy, la boucle est bouclée, business is business.
J'ai pu trouver un work around mais cela me convient moyennement: spécifier les bonnes directives dans le reverse proxy pour que ce dernier parle en HTTP/1.0 avec le sharepoint ... perte de perf, mais au moins, ca fonctionne.
Voila le bug de fou furieux qu'on a pu contourner en passant par HTTP/1.0 :
- URL accédée une fois sans cache (que des code 200 en retour -> mise en cache coté client)
- URL accédée une deuxieme fois avec cache (une majorité de code 304, qui, selon RFC HTTP, est censée être suivie d'un message (Not Modified par exemple, ce qui n'est pas le cas, je n'ai pas sniffer en hexa, mais fort probable d'avoir un au lieu du msg ...)
-- DEBUT SNIFF (data en provenance du backend) HTTP/1.1 65535 Date: Mon, 06 Feb 2006 11:01:11 GMT Server: web server Keep-Alive: timeout, maxt Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/plain
118 304 NOT MODIFIEDHTTP/1.1 304 Date: Mon, 06 Feb 2006 10:27:39 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET MicrosoftSharePointTeamServices: 6.0.2.6361 Cache-Control: private Content-Length: 16 Public-Extension: http://schemas.microsoft.com/repl-2
304 NOT MODIFIED 0
-- END SNIFF
Je n'ai jamais vu ca : - un code retour HTTP/1.1 65535, ca sent mauvais - des headers dans les data :) c'est tres fun tout ca - meme comportement Firefox / IE - comportement normal en direct sur sharepoint sans reverse proxy
Cdt
EROL MVP SPS - Club SPS wrote:
Bonjour,
Sans la version de SPS cela me semble délicat, je sais qu'il existe un doc.
sur le reverse proxy
http://www.microsoft.com/technet/prodtechnol/sppt/wss/revproxy.mspx
Cdlt
Oui, mais c'est une doc ISA server donc proprio microsoft, c'est sur que
ca va marcher. ISA server corrige bcp de bugs émis par un backend IIS
dans un contexte reverse proxy, la boucle est bouclée, business is
business.
J'ai pu trouver un work around mais cela me convient moyennement:
spécifier les bonnes directives dans le reverse proxy pour que ce
dernier parle en HTTP/1.0 avec le sharepoint ... perte de perf,
mais au moins, ca fonctionne.
Voila le bug de fou furieux qu'on a pu contourner en passant
par HTTP/1.0 :
- URL accédée une fois sans cache (que des code 200 en retour -> mise en
cache coté client)
- URL accédée une deuxieme fois avec cache (une majorité de code 304,
qui, selon RFC HTTP, est censée être suivie d'un message (Not Modified
par exemple, ce qui n'est pas le cas, je n'ai pas sniffer en hexa, mais
fort probable d'avoir un au lieu du msg ...)
-- DEBUT SNIFF (data en provenance du backend)
HTTP/1.1 65535
Date: Mon, 06 Feb 2006 11:01:11 GMT
Server: web server
Keep-Alive: timeout, maxt
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain
118
304 NOT MODIFIEDHTTP/1.1 304
Date: Mon, 06 Feb 2006 10:27:39 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 6.0.2.6361
Cache-Control: private
Content-Length: 16
Public-Extension: http://schemas.microsoft.com/repl-2
304 NOT MODIFIED
0
-- END SNIFF
Je n'ai jamais vu ca :
- un code retour HTTP/1.1 65535, ca sent mauvais
- des headers dans les data :) c'est tres fun tout ca
- meme comportement Firefox / IE
- comportement normal en direct sur sharepoint
sans reverse proxy
Sans la version de SPS cela me semble délicat, je sais qu'il existe un doc. sur le reverse proxy http://www.microsoft.com/technet/prodtechnol/sppt/wss/revproxy.mspx
Cdlt
Oui, mais c'est une doc ISA server donc proprio microsoft, c'est sur que ca va marcher. ISA server corrige bcp de bugs émis par un backend IIS dans un contexte reverse proxy, la boucle est bouclée, business is business.
J'ai pu trouver un work around mais cela me convient moyennement: spécifier les bonnes directives dans le reverse proxy pour que ce dernier parle en HTTP/1.0 avec le sharepoint ... perte de perf, mais au moins, ca fonctionne.
Voila le bug de fou furieux qu'on a pu contourner en passant par HTTP/1.0 :
- URL accédée une fois sans cache (que des code 200 en retour -> mise en cache coté client)
- URL accédée une deuxieme fois avec cache (une majorité de code 304, qui, selon RFC HTTP, est censée être suivie d'un message (Not Modified par exemple, ce qui n'est pas le cas, je n'ai pas sniffer en hexa, mais fort probable d'avoir un au lieu du msg ...)
-- DEBUT SNIFF (data en provenance du backend) HTTP/1.1 65535 Date: Mon, 06 Feb 2006 11:01:11 GMT Server: web server Keep-Alive: timeout, maxt Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/plain
118 304 NOT MODIFIEDHTTP/1.1 304 Date: Mon, 06 Feb 2006 10:27:39 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET MicrosoftSharePointTeamServices: 6.0.2.6361 Cache-Control: private Content-Length: 16 Public-Extension: http://schemas.microsoft.com/repl-2
304 NOT MODIFIED 0
-- END SNIFF
Je n'ai jamais vu ca : - un code retour HTTP/1.1 65535, ca sent mauvais - des headers dans les data :) c'est tres fun tout ca - meme comportement Firefox / IE - comportement normal en direct sur sharepoint sans reverse proxy
Cdt
bla
Parametrer le reverse proxy pour dialoguer avec IIS en http/1.0 contourne le probleme.
