# Using Http version 1.1 in InfluxDB output plugin **URL:** \ **Category:** Systems\ **Tags:** telegraf\ **Created:** [June 9, 2021, 5:25am UTC](https://community.influxdata.com/t/using-http-version-1-1-in-influxdb-output-plugin/20297 "2021-06-09T05:25:50Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Robert\_George](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/robert_george/32/3480_2.png) [@Robert\_George](https://community.influxdata.com/u/Robert_George)\ **Post date:** [June 9, 2021, 5:25am UTC](https://community.influxdata.com/t/using-http-version-1-1-in-influxdb-output-plugin/20297/1 "2021-06-09T05:25:51Z")
Hi, Is it possible to specify the HTTP version in the InfluxDB output plugin? ---
**Author:** ![Anaisdg](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/anaisdg/32/6401_2.png) [@Anaisdg](https://community.influxdata.com/u/Anaisdg)\ **Post date:** [June 10, 2021, 6:00pm UTC](https://community.influxdata.com/t/using-http-version-1-1-in-influxdb-output-plugin/20297/2 "2021-06-10T18:00:49Z")
I’m not sure. @popey do you know? ---
**Author:** ![popey](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/popey/32/7472_2.png) [@popey](https://community.influxdata.com/u/popey)\ **Post date:** [June 10, 2021, 6:11pm UTC](https://community.influxdata.com/t/using-http-version-1-1-in-influxdb-output-plugin/20297/3 "2021-06-10T18:11:08Z")
Interesting question! The plugin uses HTTP/1.1 by default. What’s the rationale for changing it? I don’t see any way in the default behaviour of the plugin to change it. One possible workaround however, would be to send the requests via a proxy, and translate to some other HTTP version there? ```auto ## HTTP Proxy override, if unset values the standard proxy environment ## variables are consulted to determine which proxy, if any, should be used. # http_proxy = "http://corporate.proxy:3128" ``` ---
**Author:** ![Robert\_George](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/robert_george/32/3480_2.png) [@Robert\_George](https://community.influxdata.com/u/Robert_George)\ **Post date:** [June 11, 2021, 2:13am UTC](https://community.influxdata.com/t/using-http-version-1-1-in-influxdb-output-plugin/20297/4 "2021-06-11T02:13:22Z")
Thanks @popey for the suggestion. Let me give more context on this. We have hosted our InfluxDB server in AWS environment and recently enabled WAF protection for our Load Balancer. After WAF was enabled we saw a spike in 400 error with message, > 400 Bad Request: invalid byte in chunk length While debugging this issue with AWS help, they told about a know issue when WAF is enabled > → Using ALB + WAF > AND > → using HTTP/2 version on the front end and sending request with chunked transfer encoding without specifying the chunk size. > > In other words, client using HTTP/2 connection on the front end without specifying Content-Length header in request may send request to backend using chunked transfer encoding without specifying the chunk size. This happens intermittently and may lead to backend sending 400 error and sometimes ALB 504 error(when backend keeps waiting for more data eventually leading to ALB 504 error). The issue is only seen when clients use HTTP/2 to send POST request with data payload but missing Content-Length header. I tried to check the Telegraf source code to confirm the HTTP version used, but I couldn’t find it. Neither I could confirm chunked Transfer encoding was used. AWS suggested three options > 1. Disable HTTP/2 on ALB and/or configure client to use HTTP/1.1 only. > > 2. Configure client to include Content-Length header in requests having data payload, if possible. > > 3. If clients only use HTTP/2 and HTTP/1.1 is not required by any client, use HTTP/2 on backend and change the target group protocol to HTTP/2. Having end to end HTTP/2 shall not have this issue. This question was to check if it is possible to enforce HTTP 1.1 version from telegraf end. Instead we disabled HTTP v2 support in Load Balancer. After we disabled the HTTP Version 2 support 400 errors stopped. ---
**Author:** ![popey](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/popey/32/7472_2.png) [@popey](https://community.influxdata.com/u/popey)\ **Post date:** [June 11, 2021, 2:19pm UTC](https://community.influxdata.com/t/using-http-version-1-1-in-influxdb-output-plugin/20297/5 "2021-06-11T14:19:22Z")
Thanks for the explanation. I _think_ [telegraf/http.go at master · influxdata/telegraf · GitHub](https://github.com/influxdata/telegraf/blob/master/plugins/outputs/influxdb/http.go#L163) is where the transport used by the InfluxDB output plugin is set. Looks to my (new, and untrained) eye that it’s using `http.Transport` which implies HTTP/1.1 rather than `http2.transport` which may imply HTTP/2. Perhaps further down the stack in one of the vendored modules, it’s using http2 by default? ---
**Author:** ![Mya](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/mya/32/10720_2.png) [@Mya](https://community.influxdata.com/u/Mya)\ **Post date:** [June 11, 2021, 2:39pm UTC](https://community.influxdata.com/t/using-http-version-1-1-in-influxdb-output-plugin/20297/6 "2021-06-11T14:39:08Z")
It looks like it might be based on the `net/http` package. I found this blurb in the docs. "Starting with Go 1.6, the http package has transparent support for the HTTP/2 protocol when using HTTPS. Programs that must disable HTTP/2 can do so by setting Transport.TLSNextProto (for clients) or Server.TLSNextProto (for servers) to a non-nil, empty map. Alternatively, the following GODEBUG environment variables are currently supported: ```auto GODEBUG=http2client=0 # disable HTTP/2 client support GODEBUG=http2server=0 # disable HTTP/2 server support GODEBUG=http2debug=1 # enable verbose HTTP/2 debug logs GODEBUG=http2debug=2 # ... even more verbose, with frame dumps ``` The GODEBUG variables are not covered by Go’s API compatibility promise. The http package’s Transport and Server both automatically enable HTTP/2 support for simple configurations. To enable HTTP/2 for more complex configurations, to use lower-level HTTP/2 features, or to use a newer version of Go’s http2 package, import [golang.org/x/net/http2](http://golang.org/x/net/http2) directly and use its ConfigureTransport and/or ConfigureServer functions. Manually configuring HTTP/2 via the [golang.org/x/net/http2](http://golang.org/x/net/http2) package takes precedence over the net/http package’s built-in HTTP/2 support." Let us know if you are still having problems.