Re: Host header

Michael Shapiro writes:
> It seems that requiring a Host header for http/1.1 will make the http
> protocol unuseable for URI's that do not have host information (eg
> URNs).
Observing the proceedings of the uri WG I see no real chance for the
URN draft to come out in the same time as http/1.1.
Consequently http/1.1 will have only URL-type URI-s.
> For URN schemes there may not be host information as part of the URN.
> This is true of the path URN scheme.  The client may use a proxy to resolve
> the URN.  And this proxy may speak http/1.1. Requiring a Host header
> would make it impossible to use the proxy.
If URN resolvers are be implemented in 1.1 servers, they will
use some new method (say URN-resolve <URN> http/1.1), and in that case
the Host header (telling the fqdn of the server) will have no effect. 
Otherwise (using GET <URN> http/1.1) URN resolvers would act as http
proxies too. (In that case they can send the http request to the origin
server with the proper Host header.)
> It would be better to add some sort of server capability negotiation.
> The client could ask if the server can handle full URLs and then based
> on the answer either send the full URI or not.
To be correct, where the draft writes on the requirement for the host header,
an additinonal sentence can be added, like this:
"Host header is mandatory when the request URI is an URL."
(But the condition is always true in http/1.1 context.)
For server capability negotiation there is the OPTIONS method (not yet
specified, used only as an example extension method) and the Public: header
(descibed in section 8.23 of the v11-00a draft) which tells the client
methods supported by the server. A good client implementation will
extract the Public header line from a response given directly by the origin
server and cache it for later perusal.
What should we do now?
I think it is high time to specify the OPTIONS method if we need it.

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Monday, 2 October 1995 07:45:45 UTC