- From: David Morris <dwm@xpasc.com>
- Date: Tue, 4 Nov 2003 11:00:42 -0800 (PST)
- Cc: <ietf-http-wg@w3.org>
What you propose requires a change to client behavior in a way that potentially reduces the integrity of the user interaction for all sites because you have a specific site you believe has a valid reason for allowing handling the redirect w/o user interaction. I don't believe endorsing this change in client behavior would be a good idea. Adding a new header or header parameter which declared a server's good intentions might be a reasonable approach. The client designers could then choose to honor the declaration or perhaps prompt the user once and remember that a specific server was approved, etc. Dave Morris On Mon, 3 Nov 2003, Mark Baker wrote: > > Hi, > > In the descriptions of each of the 301, 302, and 307 response codes of > RFC 2616, the following text can be found; > > "If the [code] status code is received in response to a request other > than GET or HEAD, the user agent MUST NOT automatically redirect the > request unless it can be confirmed by the user, since this might > change the conditions under which the request was issued." > > I believe that the conformance level should be "SHOULD NOT" rather than > "MUST NOT". > > Though I'm not familiar with the history of this requirement, it seems > self-explanatory regarding its intent; it's there as a warning, not as > a conformance statement. And while it's certainly the best approach > in the generic case (as "SHOULD NOT" would indicate), the opportunity > for a private agreement to exist between client and server should be > recognized IMO. > > In my case, the nature of the type of resource - as indicated in the > messages via link metadata - to which a POST is submitted is such that > there is no change of condition under which the request was issued. The > agent has committed to submitting the data across a trust boundary with > the expectation that a redirect is being performed in lieu of the server > acting as an intermediary for the request. > > Thanks. > > Mark. >
Received on Tuesday, 4 November 2003 14:20:01 UTC