Subject: Proposed text for "Routing Data's relationship to headers" (Issue 23)

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Mar 2013 18:14:35 +0000

The ticket reads:

> Right now, routing data (in particular, :scheme, :host and :path) 
> appear as headers along with the rest. This means that the recipient 
> needs to parse through the header collection to find them -- 
> potentially at the end. Different ways of addressing this have been 
> proposed; e.g., requiring them to be at the top of the header block, 
> or serialising them in different fields.
>

I am proposing to add the following text to both "Request" and 
"Response" subsections of the "HTTP Request/Response" section:

     All header field names starting with ":" (whether defined in this 
document or future
     extensions to this document) MUST appear before any other header 
fields.

Additionally, the following text should be moved from the Security 
Considerations section into the "HTTP Request/Response" section:

         <section title="HTTP Header Fields and HTTP/2.0 Headers">
           <t>
             At the application level, HTTP uses name-value pairs in its 
header fields.  Because HTTP/2.0
             merges the existing HTTP header fields with HTTP/2.0 
headers, there is a possibility that some
             HTTP applications already use a particular header field 
name.  To avoid any conflicts, all
             headers introduced for layering HTTP over HTTP/2.0 are 
prefixed with ":".  ":" is not a
             valid sequence in HTTP/1.* header field naming, preventing 
any possible conflict.
           </t>
         </section>

Does this look reasonable to people?

Thanks,
Alexey

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 13 Mar 2013 21:36:26 +0000

>     extensions to this document) MUST appear before any other header 

I would go a step further:

	Header fields must appear in the order :scheme, :host, :path,
	followed by any other headers starting with ':' (whether ...)
	followed by the remaining headers.

This will make life easier for any high-speed device.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.