Re: Host header (was uri handling of hosts is too restrictive)

Hello Stefan,

The 'Host:' request header in HTTP has a quite general syntax.
What actual implementations currently do is to send ACE
(punycode). They have that available anyway because they
need it for DNS lookup; at least that was the case in the
implementation I have done. Updating the HTTP protocol to
clarify such issues (or hopefully, to change this to use
UTF-8) would be nice, but I don't think it's the most
urgent thing to do.

Regards,   Martin.

At 09:49 04/02/16 +0100, Stefan Eissing wrote:


>Am 16.02.2004 um 05:56 schrieb Roy T. Fielding:
>>>But for the question of whether percent-escapes are allowed in host
>>>names, I don't think that argument holds.  Implementations are not
>>>interoperable for that case.  Faced with http://jos%C3%A9.net/, some
>>>applications percent-decode the name before calling the resolver, and
>>>some pass jos%C3%A9.net literally to the resolver.  The latter group of
>>>applications don't include a codepath for performing percent-decoding on
>>>host names because RFC-2616 and RFC-2396 promise that it's not necessary
>>>(RFC-2616 promises that the name is a host, not a reg_name, and RFC-2396
>>>promises no percent-escapes in host names).
>>
>>They don't need such a codepath.  They will fail as "not found", which
>>is all they need to do to retain interoperability during name resolution.
>
>This is not directly related to URIs, but how does the escaping/punying of
>hostnames affect the HTTP host header? As an implementor of HTTP client
>code, I wonder in which format I have to send the header value.
>
>At the moment I would just use the hostname as it appears in the URI. In order
>for that to work, both the resolver and the HTTP server code would have
>to work the same way for the request to go through. It's probably best to
>leave the equality check of different hostname spellings up to the server. But
>until all servers are upgraded, is there anything the client can do?
>
>Best regards, Stefan

Received on Monday, 16 February 2004 12:38:26 UTC