- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Wed, 30 Jan 2013 23:23:12 +0000
- To: Roberto Peon <grmocg@gmail.com>
- cc: Ted Hardie <ted.ietf@gmail.com>, "Adrien W. de Croy" <adrien@qbik.com>, Eliezer Croitoru <eliezer@ngtech.co.il>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, John C Klensin <john-ietf@jck.com>
Content-Type: text/plain; charset=ISO-8859-1 -------- In message <CAP+FsNchuV1V2+deWTwRBC5RkmzV29QjKAM1z+pWVYZaorYUyg@mail.gmail.com>, Roberto Peon writes: >I'm not sure I understand the part where you say that you'd have to >text-process the entire headers to find the fqdn. (In HTTP/1.1 you need to find the Host: header, it can be anywere, any number of times, including 0 times.) >Sending the components of the URI separately reduces the need to parse >these things, and better, since most of the time the host won't have >changed, a simple single 'if' allows us to proceed with the fqdn of the >previous request without any parsing at all. That's slightly different question IMO. The question I'm asking, is this: Are we going to have both a "URI" and a "Host:" field ? The issue here is: What if neither or both have FQDN's, what if they disagree and all that jazz... You question is more like: Are we going to transmit URI and FQDN separately ? to which my counter question is: Which "FQDN" would that be, the one from the absolute URI ? Or the one from the Host: header ? It seems to me that the sanest decision is: "All URIs MUST be absolute, but we might preparse them and transmit the fqdn separately for reasons of effciency, and we have no dedicated Host: header in HTTP/2.0" -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Wednesday, 30 January 2013 23:23:39 UTC