Re: Comments on draft-ietf-httpbis-http2-04

Jeff,

There is a long history of HTTP/1.1 servers that did not support Transfer-Encoding: chunked, and the PWG and others have spent a good 15 years harassing those (non-) implementors to get them to conform so we can do something other than print static files... :/

So whether or not we have MUSTs in the sentence, I think it is important to clearly identify the migration path from HTTP/1.1 chunking to HTTP/2.0 frames.  Making the jump from HTTP/1.1 to HTTP/2.0 will be a major effort for most vendors, and given past performance I'd like to avoid any ambiguous language that leads to implementation bugs and interoperability issues - it makes for some messy code when such mistakes are put in ROMs that can't be updated...


On Jul 9, 2013, at 3:50 PM, Jeff Pinner <jpinner@twitter.com> wrote:

> I would prefer we say something to the effect of:
> 
> If a server receives a request with a "Content-Length" header and
> the sum of the DATA frame payload lengths does not equal the value
> of the "content-length" header field, the server MUST return a 400 (Bad
> Request) error.
> 
> and remove any other MUSTs and SHOULDs. By the way, I would like to note that this is different than how the HTTP/1.1 spec handles Tranfser-Encoding. From RFC2616 Sec 4.4:
> 
> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
> 
> - Jeff
> 
> 
> On Tue, Jul 9, 2013 at 12:40 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 9 July 2013 10:12, Michael Sweet <msweet@apple.com> wrote:
> > I am uncomfortable with this wording primarily because a lot of POST usage
> > consists of streamed content - my particular interest is obviously printing,
> > but any streamed content will necessarily not be able to provide a
> > content-length header field. So instead I would suggest the following two
> > paragraphs instead:
> 
> I think that your edits capture the spirit of what was intended by the
> existing text, with far less ambiguity.  Unless I get objections,
> those can be integrated.
> 
> > My other comment is that I don't see any discussion of the Expect header,
> > nor do I see a issue on Github...
> 
> There was a brief discussion at the last interim.  The feature is in
> serious jeopardy.  See #18:
> https://github.com/http2/http2-spec/issues/18
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair