- 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