Hi, Yup, agreed, the frame-only transfers are only really implied in the spec (8.1.2.6's, "A request or response that includes a payload body _can_ include a content-length header field", my emphasis). The http 2 spec does specifically prohibit the transfer-encoding: chunked header, again implying that the framing mechanism subsumes it. There are a few libraries (like https://github.com/go-kivik/couchdb) which implement PUT without sending Content-Length, but other tools, like good old curl, which do send it.
The basic plan to transform to a chunked transfer encoding sounds right to me, and I'll keep an eye out for commits, I'm happy to test it out. Thanks! B. > On 1 Mar 2018, at 06:16, Willy Tarreau <w...@1wt.eu> wrote: > > Hi Robert, > > On Tue, Feb 27, 2018 at 08:26:01PM +0000, Robert Samuel Newson wrote: >> Hi, >> >> I use haproxy (1.8.4) with http/2 support in front of a server that speaks >> http 1.1. This is working great with one exception. Several http/2 client >> libraries are sending PUT requests without sending the Content-Length header >> (as it' not strictly needed due to the framing). > > At first I thought this was not valid but in fact it obviously is since > it is the equivalent of chunked encoding for HTTP/1. Interestingly, just > like chunked uploads are not much documented in the HTTP/1 specs, this > frame-only transfer is never mentionned in the HTTP/2 spec and I totally > overlooked it. > >> The http 1.1 request issued >> to the backend is therefore malformed as the header is required there. >> >> I think the right thing here is for haproxy to convert the PUT to a chunked >> transfer request to the backend. > > Yes I think so as well. It will be a bit tricky though. From what I'm > imagining, we'll have to add "Transfer-encoding: chunked" if the HEADERS > frame doesn't carry the END_STREAM flag and there is no Content-length > header, then all DATA frames will have to be prefixed with a chunk size > and the frame carrying the ES flag will have to cause the final empty > chunk to be sent. This one will be a bit delicate I think, as we don't > want to lose it if the output buffer is full and we want not to miss the > event. > > Also we must not do this for the CONNECT method! > > I'm adding this to the todo list of fixes for H2. I don't promise to > have it by 1.8.5 though, but I'll try. > > Thanks! > Willy
