Puppet

Our problem is Apache httpd. It has a “LimitRequestLine”:http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestline which defaults to 8190. It means httpd will refuse any URI with more than 8190 bytes.

The average “GET /development/catalog/host.domain?facts=…” has 4000 bytes. Although there is still room to grow, it is not difficult to reach the URI limit if you distribute custom facts.

Is it possible to HTTP POST instead of GET?

(if you use storeconfigs you are changing server state anyway)

David Escala wrote:

Our problem is Apache httpd. It has a “LimitRequestLine”:http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestline which defaults to 8190. It means httpd will refuse any URI with more than 8190 bytes.

Yes, I already seen that. Most of the proxy/web server have indeed a limit. I expect to see this issue resurrect from time to time. Note: I don’t think the HTTP RFC imposes a limit, so in this area Puppet behaves correctly.

The average “GET /development/catalog/host.domain?facts=…” has 4000 bytes. Although there is still room to grow, it is not difficult to reach the URI limit if you distribute custom facts.

Is it possible to HTTP POST instead of GET?

I don’t think so, because we’re GETting a catalog. To be RESTful, we should keep using GET.

(if you use storeconfigs you are changing server state anyway)

No. Storeconfigs doesn’t change the state of the server. It just “caches” the configuration somewhere else.

What could be done is to maybe gzip the facts before using them as a request parameter.

Brice Figureau wrote:

What could be done is to maybe gzip the facts before using them as a request parameter.

Gzip == binary format == lots more escape sequences in the request. I think the gzipped and URL-escaped request would be as long as the original data, or maybe even longer.

Doesn’t this just mean the answer is to document that you need to increase LimitRequestLine for your vhost ?

AFAIK you can only set the LimitRequestLine to a value between 0 and DEFAULT_LIMIT_REQUEST_LINE ( which is 8190 usually, and set at Apache compiletime.. ). So i guess you cannot increase it, only decrease.. Or am i missing something?

Josh Anderson wrote:

Brice Figureau wrote:

What could be done is to maybe gzip the facts before using them as a request parameter.

Gzip == binary format == lots more escape sequences in the request. I think the gzipped and URL-escaped request would be as long as the original data, or maybe even longer.

I was thinking about gzip + base64 actually. It might be interesting to try.

Brice Figureau wrote:

Josh Anderson wrote:

Brice Figureau wrote:

What could be done is to maybe gzip the facts before using them as a request parameter.

Gzip == binary format == lots more escape sequences in the request. I think the gzipped and URL-escaped request would be as long as the original data, or maybe even longer.

I was thinking about gzip + base64 actually. It might be interesting to try.

I just tried on some of my facts:

• verbatim: 3799 bytes
• gzipped: 1614 bytes
• gz+base64: 2181 bytes

So in the end the compression ratio is: 57% which is not that bad…

Making the same caculations:

* verbatim: 6835 bytes
* gzipped: 1939 bytes
* gz+base64: 2623 bytes

It doesn’t totally solve the problem, but it surely makes it a lot harder to trigger :)

master and agent are version 0.25.4 both

Having the same issue with a host that has a large number (over 180) of IP addresses attached, thereby giving MANY interface related facts. I’m using 0.26.4 for both master/agent.

facter | wc 773 2412 29574

Mark – do you mean 2.6.4? Or 0.25.4?