- From: Florent Georges <fgeorges@fgeorges.org>
- Date: Fri, 17 Apr 2009 00:37:07 +0200
- To: Norman Walsh <ndw@nwalsh.com>
- Cc: public-xml-processing-model-comments@w3.org
2009/4/16 Norman Walsh wrote: > If there are good reasons not to follow redirects, we expect > implementors will support users by adding an extension attribute to > support that behavior. The WG can take this as input for some future > version. Sounds wise. > In short, we're content with 7.1.10.3.1 as it stands in the current > editor's draft. I don't like this section for two reasons: 1/ I'd prefer SHOULD than MUST, as I can imagine implementors could have good reason not to do so, and 2/ it does not make any difference regarding the method, while the HTTP RFC allows an implementation to follow redirect only for GET and HEAD (technically, an implementation couldn't be both HTTP and XProc conformant.) > On a personal note, can you explain how the Google use of redirects > for authentication requires a pipeline to *not* follow the redirect in > order to access the API? I would have thought that was a case were > following the redirect (perhaps with cookies preserved) was > *necessary*. Really, I'd like to give you an answer, but I do not have anyone :-/ Two months is a long time ;-) If I remember well, I got an implementation that followed a 302 on a POST request, and followed the redirection as a GET (while the authentication info were in the body.) This is not conformant to the HTTP RFC, and I can't find doc about that in GData authentication. So maybe my memories are playing with me... Regards, -- Florent Georges http://www.fgeorges.org/
Received on Thursday, 16 April 2009 22:37:48 UTC