Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Graylog 3.0.0. broke 100-Expect #5690

Closed
mikkolehtisalo opened this issue Feb 19, 2019 · 2 comments
Closed

Graylog 3.0.0. broke 100-Expect #5690

mikkolehtisalo opened this issue Feb 19, 2019 · 2 comments

Comments

@mikkolehtisalo
Copy link
Contributor

@mikkolehtisalo mikkolehtisalo commented Feb 19, 2019

Expected Behavior

The 100-Expect should work for HTTP inputs. See #1939 for information (related RFC, etc).

Current Behavior

After client sends
POST /gelf HTTP/1.1 Content-Type: application/json; charset=utf-8 Host: server:444 Content-Length: 304 Expect: 100-continue Connection: Keep-Alive
Graylog silently decides to close connection.

Possible Solution

No idea. Probably the Netty upgrade broke this between 2.5.0 and 3.0.0.

Steps to Reproduce (for bugs)

  1. Configure HTTP input
  2. Use client that utilizes 100-Expect
  3. The problem repdocudes

Context

I wouldn't care otherwise, but .NET based clients and Microsoft's default libraries want to use this feature. Disabling the feature from clients is possible, but extra work.

Your Environment

  • Graylog Version: 3.0.0
  • Elasticsearch Version: 5.6.x
  • MongoDB Version: 4.x
  • Operating System: Linux
  • Browser version: Any
@mikkolehtisalo
Copy link
Contributor Author

@mikkolehtisalo mikkolehtisalo commented Feb 19, 2019

I believe this might be related:

2019-02-19T12:40:17.001+02:00 ERROR [AbstractTcpTransport] Error in Input [GELF HTTP/57cfeeb43e8b28286339d9d9] (channel [id: 0xdd6b11e5, L:/xx.xx.xx.xx:xx ! R:/xx.xx.xx.xx3:44478]) (cause java.lang.UnsupportedOperationException: unsupported message type: DefaultFullHttpResponse (expected: ByteBuf, DefaultFileRegion))
@wrigley418
Copy link

@wrigley418 wrigley418 commented Feb 22, 2019

I observe the same results. It was working with 2.5.1+34194da, but received error mentioned above when running new 3.0 release. I viewed a packet capture and my HTTP client is also sending "Expect: 100-Continue"

@mpfz0r mpfz0r self-assigned this Feb 26, 2019
mpfz0r added a commit that referenced this issue Feb 26, 2019
Requests with `Expect: 100-Continue` would lead to an exception and
terminate the request.
This got broken with the netty upgrade, which exchanged the
`HttpChunkedAggregator` to the new `HttpObjectAggregator`.

The aggregator needs to be registered after the `HttpResponseEncoder`
in the ChannelPipeline.
Ref: https://netty.io/4.1/api/io/netty/handler/codec/http/HttpObjectAggregator.html

Fixes #5690
dennisoelkers added a commit that referenced this issue Mar 13, 2019
Requests with `Expect: 100-Continue` would lead to an exception and
terminate the request.
This got broken with the netty upgrade, which exchanged the
`HttpChunkedAggregator` to the new `HttpObjectAggregator`.

The aggregator needs to be registered after the `HttpResponseEncoder`
in the ChannelPipeline.
Ref: https://netty.io/4.1/api/io/netty/handler/codec/http/HttpObjectAggregator.html

Fixes #5690
mpfz0r added a commit that referenced this issue Mar 13, 2019
Requests with `Expect: 100-Continue` would lead to an exception and
terminate the request.
This got broken with the netty upgrade, which exchanged the
`HttpChunkedAggregator` to the new `HttpObjectAggregator`.

The aggregator needs to be registered after the `HttpResponseEncoder`
in the ChannelPipeline.
Ref: https://netty.io/4.1/api/io/netty/handler/codec/http/HttpObjectAggregator.html

Fixes #5690

(cherry picked from commit bc4301f)
dennisoelkers added a commit that referenced this issue Mar 13, 2019
Requests with `Expect: 100-Continue` would lead to an exception and
terminate the request.
This got broken with the netty upgrade, which exchanged the
`HttpChunkedAggregator` to the new `HttpObjectAggregator`.

The aggregator needs to be registered after the `HttpResponseEncoder`
in the ChannelPipeline.
Ref: https://netty.io/4.1/api/io/netty/handler/codec/http/HttpObjectAggregator.html

Fixes #5690

(cherry picked from commit bc4301f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants