Topics

Set maxHttpHeaderSize in tomcat server as a parameter


sajjadgholami2006@...
 

Hi there,

We have a service that gets http requests with big header size, so I was wondering if we can just expose a parameter to set the maximum http header size in tomcat/conf/server.xml to be set by a new option in tomcat.yml file (e.g. "maxHttpHeaderSize" under "tomcat").
I can create a pull-request for this.

I'll appreciate your input ;)

Best,
Sajjad


Lingesh Mouleeshwaran
 

Hello Sajjad, 

your expected changes are available in my git repo. 
https://github.com/hmlingesh/java-buildpack/commit/5ae18c3fdd873837bcb9427b5659ef52239b30a1  Please have a look I will make a pull request for the same.

Note: by default, Apache community give 8kb as default header size, also I prefer to keep 64 kb as default. 

Regards
Lingesh M

On Fri, Sep 14, 2018 at 6:02 AM, <sajjadgholami2006@...> wrote:
Hi there,

We have a service that gets http requests with big header size, so I was wondering if we can just expose a parameter to set the maximum http header size in tomcat/conf/server.xml to be set by a new option in tomcat.yml file (e.g. "maxHttpHeaderSize" under "tomcat").
I can create a pull-request for this.

I'll appreciate your input ;)

Best,
Sajjad



Daniel Mikusa
 

Have you tried the support that's already in the Java buildpack for customizing Tomcat configuration?


This lets you configure all aspects of Tomcat's config, not just the header size.

Dan


On Sat, Sep 15, 2018 at 7:08 AM, Lingesh Mouleeshwaran <lingeshmouleeshwaran@...> wrote:
Hello Sajjad, 

your expected changes are available in my git repo. 
https://github.com/hmlingesh/java-buildpack/commit/5ae18c3fdd873837bcb9427b5659ef52239b30a1  Please have a look I will make a pull request for the same.

Note: by default, Apache community give 8kb as default header size, also I prefer to keep 64 kb as default. 

Regards
Lingesh M

On Fri, Sep 14, 2018 at 6:02 AM, <sajjadgholami2006@...> wrote:
Hi there,

We have a service that gets http requests with big header size, so I was wondering if we can just expose a parameter to set the maximum http header size in tomcat/conf/server.xml to be set by a new option in tomcat.yml file (e.g. "maxHttpHeaderSize" under "tomcat").
I can create a pull-request for this.

I'll appreciate your input ;)

Best,
Sajjad




sajjadgholami2006@...
 
Edited

Thanks Lingesh for sharing your repo; right I actually did try it on my own repo as well, but we want it to be formally accepted and be in the original build-pack to use.

Daniel, you're right; but again this needs another repo to be setup, we want to only trust the one formal original CF repo that has the community watching it instead of moving to unreliable sources or to create and maintain our own repo besides this that's why I'm suggesting to make the change in original repo :)


Lingesh Mouleeshwaran
 

Alright Thanks, Sajjid, Let me create a pull request for the same. Need to wait for the community concerns as well

On Mon, Sep 17, 2018 at 10:58 PM, <sajjadgholami2006@...> wrote:

[Edited Message Follows]

Thanks Lingesh for sharing your repo; right I actually did try it on my own repo as well, but we want it to be formally accepted and be in the original build-pack to use.

Daniel, you're right; but again this needs another repo to be setup, we want to only trust the one formal original CF repo that has the community watching it instead of moving to unreliable sources or to create and maintain our own repo besides this that's why I'm suggesting to make the change in original repo :)



sajjadgholami2006@...
 

Thanks Lingesh,

We can argue that this is kind of needed for CF services, due to the nature of using JWT token in header; if you want to put something convincing in the pull-request comment ;) 


Daniel Mikusa
 

On Mon, Sep 17, 2018 at 1:28 PM, <sajjadgholami2006@...> wrote:

[Edited Message Follows]

Thanks Lingesh for sharing your repo; right I actually did try it on my own repo as well, but we want it to be formally accepted and be in the original build-pack to use.

Daniel, you're right; but again this needs another repo to be setup, we want to only trust the one formal original CF repo that has the community watching it instead of moving to unreliable sources or to create and maintain our own repo besides this that's why I'm suggesting to make the change in original repo :)

Not sure what you mean. It doesn't require that you fork the buildpack. You just need to host your Tomcat config somewhere. That's cause the buildpack will need to download it, since it's not part of the JBP. The easiest way is to push your config w/the Staticfile buildpack. Then you can use `cf set-env` and tell the JBP to use your external config bundle from your Staticfile app. You could post the config elsewhere too, like S3 or any other HTTP server.

Dan


 



sajjadgholami2006@...
 

I see what you mean Dan, I know that it doesn't need the whole repo to be forked and it's just tomcat configuration; but that still needs another 'public' repo to host the tomcat customized configuration. Look at it from a corporation's view, they don't want to trust more repositories than the formal open source repos having a support of a community and it's secure since the community has it under control, instead of my own public repo that I can mess it up anytime. That's my whole point, it can be a parameter exposed in the formal code base which everyone has trust on. 


Daniel Mikusa
 

On Mon, Sep 17, 2018 at 4:55 PM, <sajjadgholami2006@...> wrote:
I see what you mean Dan, I know that it doesn't need the whole repo to be forked and it's just tomcat configuration; but that still needs another 'public' repo to host the tomcat customized configuration.

It doesn't have to be public. It can be on a company's internal network. It just needs to be accessible from the platform where the buildpack is running. That's why it's convenient to use the Staticfile buildpack and host the config on the platform itself.
 
Look at it from a corporation's view, they don't want to trust more repositories than the formal open source repos having a support of a community and it's secure since the community has it under control, instead of my own public repo that I can mess it up anytime.

I wouldn't expect anyone to trust a random repo from the internet. They'd want to host their own Tomcat config on a server they control, like an app they push to their platform using the Staticfile buildpack.

Anyway, I probably do not fully understand your use case and that's OK. I just wanted to suggest this other option in case it might work for you.

Dan

 
That's my whole point, it can be a parameter exposed in the formal code base which everyone has trust on. 



Lingesh Mouleeshwaran
 

Hello All, 


Regards
Lingesh M

On Tue, Sep 18, 2018 at 8:06 AM, Daniel Mikusa <dmikusa@...> wrote:
On Mon, Sep 17, 2018 at 4:55 PM, <sajjadgholami2006@...> wrote:
I see what you mean Dan, I know that it doesn't need the whole repo to be forked and it's just tomcat configuration; but that still needs another 'public' repo to host the tomcat customized configuration.

It doesn't have to be public. It can be on a company's internal network. It just needs to be accessible from the platform where the buildpack is running. That's why it's convenient to use the Staticfile buildpack and host the config on the platform itself.
 
Look at it from a corporation's view, they don't want to trust more repositories than the formal open source repos having a support of a community and it's secure since the community has it under control, instead of my own public repo that I can mess it up anytime.

I wouldn't expect anyone to trust a random repo from the internet. They'd want to host their own Tomcat config on a server they control, like an app they push to their platform using the Staticfile buildpack.

Anyway, I probably do not fully understand your use case and that's OK. I just wanted to suggest this other option in case it might work for you.

Dan

 
That's my whole point, it can be a parameter exposed in the formal code base which everyone has trust on. 




sajjadgholami2006@...
 

Thanks Dan, I know you are trying to help me with other options, but we already considered those options. As Lingesh mentioned in the PR message, this is happening in more CF services now with moving to JWT and it's sort of blocking the basic functionalities; so it's much better to have it in main repo :)

Thanks a lot Lingesh for making the PR, I'll follow that and use it whenever it's merged :)

Best,
Sajjad


Lingesh Mouleeshwaran
 

Thanks, Sajjad !!!

On Tue, Sep 18, 2018 at 10:56 PM, <sajjadgholami2006@...> wrote:
Thanks Dan, I know you are trying to help me with other options, but we already considered those options. As Lingesh mentioned in the PR message, this is happening in more CF services now with moving to JWT and it's sort of blocking the basic functionalities; so it's much better to have it in main repo :)

Thanks a lot Lingesh for making the PR, I'll follow that and use it whenever it's merged :)

Best,
Sajjad