Re: http_first_req not working with http2
On Tue, Jun 04, 2019 at 10:32:19AM -0400, Patrick Hemmer wrote: > The use case was that I was trying to log SSL data (via a Lua script) when > the connection is first established. If the frontend is operating in http > mode (as opposed to tcp), we can only apply actions on receipt of a request, > and not after connection is established. Thus I was trying to use > http_first_req to trigger the action only on the first request. Ah OK got it. In this case you would never even be certain to log it in H2, if for some reason the first request was invalid for example you could end up processing all other ones but not the first one. > I suppose an alternate that might work would be to add support for using Lua > actions with `tcp-request session`. Yes, "tcp-request session" is indeed more suitable for this. Willy
Re: http_first_req not working with http2
*From:* Willy Tarreau [mailto:w...@1wt.eu] *Sent:* Tuesday, June 4, 2019, 10:08 EDT *To:* Patrick Hemmer *Cc:* haproxy@formilux.org *Subject:* http_first_req not working with http2 Hi Patrick, On Mon, Jun 03, 2019 at 05:21:26PM -0400, Patrick Hemmer wrote: As subject says, it appears that the http_first_req sample is not working with http2. Indeed, the first request in H1 is special in that it is not automatically retryable. In H2 it's different, all requests are totally independant and there is not even any real ordering. Since it is possible to use GOAWAY to cleanly close a connection, no H2 request suffers from the limitations of the first H1 request, so none of them is marked first. At the very least this should be mentioned in the doc. Do you have a particular use case that relies on this and which would need any form of emulation of this older behaviour ? I couldn't find any but maybe there are. Thanks, Willy The use case was that I was trying to log SSL data (via a Lua script) when the connection is first established. If the frontend is operating in http mode (as opposed to tcp), we can only apply actions on receipt of a request, and not after connection is established. Thus I was trying to use http_first_req to trigger the action only on the first request. I suppose an alternate that might work would be to add support for using Lua actions with `tcp-request session`. -Patrick
Re: http_first_req not working with http2
Hi Patrick, On Mon, Jun 03, 2019 at 05:21:26PM -0400, Patrick Hemmer wrote: > As subject says, it appears that the http_first_req sample is not working > with http2. Indeed, the first request in H1 is special in that it is not automatically retryable. In H2 it's different, all requests are totally independant and there is not even any real ordering. Since it is possible to use GOAWAY to cleanly close a connection, no H2 request suffers from the limitations of the first H1 request, so none of them is marked first. At the very least this should be mentioned in the doc. Do you have a particular use case that relies on this and which would need any form of emulation of this older behaviour ? I couldn't find any but maybe there are. Thanks, Willy
Re: http_first_req not working with http2
*From:* Patrick Hemmer [mailto:hapr...@stormcloud9.net] *Sent:* Monday, June 3, 2019, 17:21 EDT *To:* haproxy@formilux.org *Subject:* http_first_req not working with http2 As subject says, it appears that the http_first_req sample is not working with http2. Config: frontend f1 bind :8000 option http-use-htx log-format http_first_req=%[http_first_req] With `curl http://localhost:8000` Outputs: <30>Jun 3 17:16:36 haproxy[47767]: http_first_req=1 Where as, Config: frontend f1 bind :8000 proto h2 option http-use-htx log-format http_first_req=%[http_first_req] With `curl --http2-prior-knowledge http://localhost:8000` Outputs: <30>Jun 3 17:16:51 haproxy[47829]: http_first_req=0 -Patrick Oh, forgot the version. 1.9.8 -Patrick
