Re: SPDY Header Frames

On 16.07.2012 12:52, James M Snell wrote:
> On Sun, Jul 15, 2012 at 1:58 AM, Amos Jeffries wrote:
>
>> On 15/07/2012 7:07 p.m., Poul-Henning Kamp wrote:
>>
>>> Amos Jeffries writes:
>>>
>>>  Hopefully the result will be a BIG change towards simplicity. But 
>>> only
>>>> time will tell about that.
>>>>
>>> I don't see any signs of that anywhere, care to elaborate what you
>>> base your hope on ?
>>>
>>>
>> "Hope is hope. If we had reasons, it'd be called surety" - 
>> Anonymous.
>>
>> We have the opportunity for reducing the HTTPbis specs into one spec 
>> which
>> describeds the framing for HTTP/2 and flor controls. Leaving the 
>> rest of
>> the protocol features out as separate optional extensions. There is 
>> hope,
>> slim maybe, but hope.
>>
>>
> While "leaving the rest ... out as separate optional extensions" 
> sounds
> great if you're in the business of providing the fundamental 
> architecture,
> it's not so great if you're building applications on top that rely on 
> those
> "optional" pieces. Simplification is a great thing, but HTTP/2 can't 
> be
> ONLY about the framing... it must also address very real issues that 
> exist
> elsewhere in the specification.

This sounds like you are arguing that we need to force mandatory Range: 
request support, mandatory caching, mandatory authentication, etc, etc. 
all the way down the stack from the web application which needs it, to 
the simple load balancers or "HTTP router" pushing HTTP/2 around a CDN 
hierarchy.

I agree that application level implementations have a whole bunch of 
things they need to support. Browsers being probably the best example 
here, with have a far wider range of RFCs to support today than even 
just HTTP/1.1. CGI interface libraries not being far behind.


I'm questioning why implementers have to be faced with reading and 
verifying compliance of all this detail as "The HTTP/2.0 Document" when 
the request details are controlled by an application and the reply is 
generated by one. Consider an HTTP server which runs a simple CGI 
library. The server can decode and multiplex the framing, but has no 
need to handle or even implement most of the finer details for features 
the CGI library can cope with. It just needs to pass on the request and 
assemble the response bits (CGI could encoded its specific 
application-level headers easily enough).
  -> the server needs compliance with HTTP/2
  -> the CGI needs compliance with some application feature spec(s) it 
want to implement and HTTP/2


To take this to the extreme case;  Should we also borg the entirety of 
WebDAV (an application feature definition) into the HTTP/2.0 document 
just because web application layer needs it? I think not.
  Neither do I think www-auth should be part of the core HTTP/2 
specification. As opposed to proxy-auth in its role as connection 
authentication which *is* relevant to the transport level for even 
simple load balancers to handle properly.
  The SPDY draft is a good example of creeping the scope out beyond 
transport and the disagreements have *all* been focused around different 
"groups" needs being unmet by that all-in-one spec.


If you read PHKs' arguments about spec page length with a grain of 
salt, these same points are what he is arguing about.

A lot of the features we will be wanting to keep from HTTP/1.x 
(www-auth, ranges, caching etc being good ones). Describing their 
semantics in a separate document pointed at by both HTTP/2 and HTTP/1 
would be a great way to simplify the texts and ensure semantic 
compatibility. New features may well be needing to define HTTP/1 
backward compatibility and this style of specification would make it 
easier to extend 1.1+


Come to think of it, in our network-friendly draft we only specify 
version as far as "HTTP/2", the .x part is left unstated in the frame 
headers and could be added as a capabilities header minor version hint, 
with a finer grain of capability advertisement than then 1.x style of 
1/2/3/4/etc offers.


A lot of the things we want to do are use-case specific wants/needs. I 
simply want the thing calling itself HTTP/2.0 to state "X,Y,Z are 
REQUIRED". That is all. When we have a choice to specify something 
optional elsewhere lets do so.

AYJ


Afterword: WG editors; that opinion goes for the HTTPbis drafts final 
arrangement choices as well.

Received on Monday, 16 July 2012 01:44:10 UTC