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

Add support for configuring the HttpRequestDecoder when creating an HttpServer #150

Closed
wilkinsona opened this issue Aug 4, 2017 · 2 comments · Fixed by #263
Closed

Add support for configuring the HttpRequestDecoder when creating an HttpServer #150

wilkinsona opened this issue Aug 4, 2017 · 2 comments · Fixed by #263
Labels
type/enhancement A general enhancement
Milestone

Comments

@wilkinsona
Copy link

A Spring Boot user has raised an issue that's caused by Netty's default configuration that limits the initial line of an HTTP request to 4096 bytes. As far as I can tell, Reactor Netty doesn't allow this to be configured as the default HttpRequestDecoder constructor is used.

Would it be possible to expose the configuration options offered by HttpRequestDecoder to users?

@balopat
Copy link

balopat commented Dec 7, 2017

+1

simonbasle added a commit that referenced this issue Jan 4, 2018
This commits exposes options from Netty's HttpServerCodec (that is
maxInitialLineLength, maxHeaderSize and maxChunkSize) through our
HttpServerOptions. This should allow the codec to decode requests
on very long URIs.
simonbasle added a commit that referenced this issue Jan 9, 2018
This commits allows to configure Netty's HttpServerCodec 5 options for
request decoding, through an HttpServer API that consumes a small simple
builder which holds the parameters. Parameters are then injected as
Channel attributes.

This would notably allow the codec to decode requests on very long URIs.
simonbasle added a commit that referenced this issue Jan 9, 2018
This commits allows to configure Netty's HttpServerCodec 5 options for
request decoding, through an HttpServer API that consumes a small simple
builder which holds the parameters. Parameters are then injected as
Channel attributes.

This would notably allow the codec to decode requests on very long URIs.
violetagg pushed a commit that referenced this issue Jan 15, 2018
This commits allows to configure Netty's HttpServerCodec 5 options for
request decoding, through an HttpServer API that consumes a small simple
builder which holds the parameters. Parameters are then injected as
Channel attributes.

This would notably allow the codec to decode requests on very long URIs.
@violetagg
Copy link
Member

Covered by #256

violetagg pushed a commit that referenced this issue Jan 15, 2018
This commits allows to configure Netty's HttpServerCodec 5 options for
request decoding, through an HttpServer API that consumes a small simple
builder which holds the parameters. Parameters are then injected as
Channel attributes.

This would notably allow the codec to decode requests on very long URIs.
violetagg pushed a commit that referenced this issue Jan 17, 2018
This commits allows to configure Netty's HttpServerCodec 5 options for
request decoding, through an HttpServer API that consumes a small simple
builder which holds the parameters. Parameters are then injected as
Channel attributes.

This would notably allow the codec to decode requests on very long URIs.
simonbasle added a commit that referenced this issue Jan 18, 2018
This commits exposes options from Netty's HttpServerCodec (that is
maxInitialLineLength, maxHeaderSize and maxChunkSize) through our
HttpServerOptions. This should allow the codec to decode requests
on very long URIs.
smaldini pushed a commit that referenced this issue Jan 18, 2018
This commits exposes options from Netty's HttpServerCodec (that is
maxInitialLineLength, maxHeaderSize and maxChunkSize) through our
HttpServerOptions. This should allow the codec to decode requests
on very long URIs.
violetagg pushed a commit that referenced this issue Jan 19, 2018
This commits allows to configure Netty's HttpServerCodec 5 options for
request decoding, through an HttpServer API that consumes a small simple
builder which holds the parameters. Parameters are then injected as
Channel attributes.

This would notably allow the codec to decode requests on very long URIs.
violetagg pushed a commit that referenced this issue Jan 22, 2018
This commits allows to configure Netty's HttpServerCodec 5 options for
request decoding, through an HttpServer API that consumes a small simple
builder which holds the parameters. Parameters are then injected as
Channel attributes.

This would notably allow the codec to decode requests on very long URIs.
violetagg pushed a commit that referenced this issue Jan 24, 2018
This commits allows to configure Netty's HttpServerCodec 5 options for
request decoding, through an HttpServer API that consumes a small simple
builder which holds the parameters. Parameters are then injected as
Channel attributes.

This would notably allow the codec to decode requests on very long URIs.
@violetagg violetagg mentioned this issue May 14, 2018
24 tasks
violetagg pushed a commit that referenced this issue May 16, 2018
This commits allows to configure Netty's HttpServerCodec 5 options for
request decoding, through an HttpServer API that consumes a small simple
builder which holds the parameters. Parameters are then injected as
Channel attributes.

This would notably allow the codec to decode requests on very long URIs.
violetagg pushed a commit that referenced this issue May 28, 2018
This commits allows to configure Netty's HttpServerCodec 5 options for
request decoding, through an HttpServer API that consumes a small simple
builder which holds the parameters. Parameters are then injected as
Channel attributes.

This would notably allow the codec to decode requests on very long URIs.
@violetagg violetagg modified the milestones: 0.8.0.RELEASE, 0.8.0.M1 Jun 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement A general enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants