- From: Gisle Aas <gisle@aas.no>
- Date: Fri, 20 Mar 1998 16:12:33 GMT
- To: http-wg@cuckoo.hpl.hp.com
- Cc: libwww-perl@ics.uci.edu
I am trying to update libwww-perl to deal with automatic redirect as specified by HTTP/1.1. I am reading <draft-ietf-http-v11-spec-rev-03>. First some comments: 1) Perhaps there should be a note explaining why there is no code for 306 (if there is a reason)? 2) The "Note:" for 305 says: > Note: RFC 2068 was not clear that 305 was intended to redirect a > single request, or to be generated by origin servers only. Not > observing these limitations has significant security consequences. I can not parse this sentence within this context without substituting "or" with "and". Is this just a typo? And then some question I hope you can clarify? A common phrase for all descriptions are: > If the new URI is a location, its URL SHOULD be given by the Location > field in the response. but I don't understand what the case of "the new URI" not being a location would imply? If I summarize the behaviour prescribed I get this table (I only care about the client behaviour): PREREQ METHOD URI PROXY ------------- ------ ---------- ----------- 301 GET|HEAD|ask same Location - 302 GET|HEAD|ask same Location - 303 - GET Location - 305 - same same Location 307 GET|HEAD|ask same Location - "ask" means to ask the user if resending the request to the new location is ok. 302 and 307 are described to be identical, but the notes seems to indicate that 302 would better be implemented as 303 to conform to what most browsers do. Should I do that? If the original method was HEAD, then I assume that the sensible thing to do for 303 is to use HEAD (not GET) in the redirect requests too. Agree? Why is there no demand for "confirmation by the user" for 305 request? Regards, Gisle Aas
Received on Monday, 23 March 1998 09:26:32 UTC