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

Comments

Projects
None yet
4 participants
@mikkolehtisalo
Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link

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

Fix HTTP 100 handling in http inputs
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

Fix HTTP 100 handling in http inputs (#5725)
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

Fix HTTP 100 handling in http inputs (#5725)
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

Fix HTTP 100 handling in http inputs (#5725) (#5768)
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
You can’t perform that action at this time.