- From: Ari Luotonen <luotonen@netscape.com>
- Date: Thu, 21 Sep 1995 17:47:11 -0700 (PDT)
- To: Albert Lunde <Albert-Lunde@nwu.edu>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Most importantly, Phillip M. Hallam-Baker mentioned needing the URI for the > keyed digest authentication scheme... I'm not sure if this is still an > issue... perhaps he could comment. There is no reason why digest authentication can't reconstruct the original URL from its four parts: http:// or https:// prefix (implicitly known to the server), contents of Host:, possibly non-default port number (implicitly known), and the path info passed in the request. > A couple of people mentioned interaction with proxies, either that Orig-URI > could be used by proxies or that it was useful to have the URI unmodified > by proxies (I guess URN resolution would be a related case to this.) Intermediate proxies shouldn't modify the URL encoding when forwarding the request. Netscape proxy doesn't, and if I recall, CERN doesn't either (at least I didn't mean it to, but it may have been broken in 3.0 after I left, but I think there's a patch for it, too). A much more useful thing to do in the spec would be to require proxies to leave the URL pathinfo untouched. If it really becomes an issue, then the *digest authentication* can define its own new header, but there's no reason for *every* HTTP request to be burdened by it. > Someone suggested that it would be useful for more general "smart > redirects" and that having the fragment identifier might be useful. You can have a new header for those smart redirects, again no need to burden every request and response with them. So, still strongly seconding making Host: mandatory in HTTP/1.1. Cheers, -- Ari Luotonen ari@netscape.com Netscape Communications Corp. http://home.netscape.com/people/ari/ 501 East Middlefield Road Mountain View, CA 94043, USA Netscape Server Development Team
Received on Thursday, 21 September 1995 17:49:14 UTC