Re: http/2 PUT's without content-length fail to http 1.1 backend

Hi Robert, On Sat, Mar 10, 2018 at 06:16:21PM +, Robert Samuel Newson wrote: > Hi, > > Whenever you look into this, I noticed that a streamed upload also fails, but > differently; > > cat | acurl https://rnewson.cloudant.com/db1/doc1/att1 -XPUT -T- > > curl chooses http/2 and sends the

Re: http/2 PUT's without content-length fail to http 1.1 backend

Hi, Whenever you look into this, I noticed that a streamed upload also fails, but differently; cat | acurl https://rnewson.cloudant.com/db1/doc1/att1 -XPUT -T- curl chooses http/2 and sends the Transfer-Encoding: chunked header, and then streams the file. The result is that the body is not

Re: http/2 PUT's without content-length fail to http 1.1 backend

On Thu, Mar 01, 2018 at 09:38:10AM +, Robert Samuel Newson wrote: > 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 >

Re: http/2 PUT's without content-length fail to http 1.1 backend

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

http/2 PUT's without content-length fail to http 1.1 backend

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). The http 1.1