> Am 17.11.2015 um 13:13 schrieb Plüm, Rüdiger, Vodafone Group > <ruediger.pl...@vodafone.com>: >> -----Ursprüngliche Nachricht----- >> Von: Stefan Eissing >> Gesendet: Dienstag, 17. November 2015 12:58 >> An: dev@httpd.apache.org >> Betreff: Re: svn commit: r1714751 - >> /httpd/httpd/trunk/modules/http2/h2_request.c >> >> There is no "Transfer-Encoding" header in HTTP/2. When forwarding the >> request for processing into httpd core, there are currently two paths: >> - H2SerializeHeaders off (default), where request_rec is created >> directly >> and >> - H2SerializeHeaders on, where the slave connection carries a serialized >> HTTP/1.1 request that is parsed and processed as if it where a real >> client connection. >> >> if content-length has not been specified in the HTTP/2 request, the code >> - adds "Transfer-Encoding" if DATA is to be expected (no EOS signaled) >> - adds "Content-Length: 0" if EOS has already been signaled. This is to >> allow the eventual HTTP/1.1 request parsing to know that no data will >> come. Adding this only for requests with "Content-Type" present is >> up for discussion. I want to avoid adding headers to common requests >> that do not normally carry a body, like GET, DELETE, HEAD and others. > > From performance point of view this is quite understandable, but we need to > ensure that we do not open > up the door for request smuggling.
By which you mean sneaking in a request inside the body of another one, confusing boundaries? Fair enough. The job of preventing that lies in the HTTP/2 framing layer which also keeps the stream states. Sending any more HEADER/DATA frames for a closed stream is a protocol error and must lead to termination of the connection. If the framing layer does its job, signaling an end-of-stream - means there will not be any more DATA to come - therefore the request input is complete and has 0 length But mistakes are easily made and I appreciated that you're looking critically at this. //Stefan > > Regards > > Rüdiger
