The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #2668

Too many facts: request-URI Too Large

Added by David Escala about 5 years ago. Updated about 2 years ago.

Status:DuplicateStart date:09/22/2009
Priority:NormalDue date:
Assignee:James Turnbull% Done:

100%

Category:plumbing
Target version:-
Affected Puppet version:0.25.4 Branch:tickets/0.25/2668
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

Puppet client says

err: Could not retrieve catalog from remote server: Error 414 on SERVER: Request-URI Too Large

when facter URL is too large.

# facter | wc
     75     295    5947

Note we are using @http_proxy_host@. I do not know if that matters.


Related issues

Related to Puppet - Bug #4313: request-URI Too Large with ruby 1.8.1 Closed 07/21/2010
Related to Puppet - Bug #6117: Catalog GETs should shift to POST Closed 02/02/2011

History

#1 Updated by James Turnbull about 5 years ago

  • Category set to plumbing
  • Status changed from Unreviewed to Accepted
  • Target version set to 0.25.2

#2 Updated by David Escala about 5 years ago

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)

#3 Updated by Brice Figureau about 5 years ago

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.

#4 Updated by Josh Anderson about 5 years ago

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.

#5 Updated by Nigel Kersten about 5 years ago

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

#6 Updated by Bart Verwilst about 5 years ago

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?

#7 Updated by Brice Figureau about 5 years ago

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.

#8 Updated by Brice Figureau about 5 years ago

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…

#9 Updated by Bart Verwilst about 5 years ago

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 :)

#10 Updated by Brice Figureau about 5 years ago

  • Status changed from Accepted to Ready For Checkin
  • Assignee set to James Turnbull
  • % Done changed from 0 to 100
  • Branch set to tickets/0.25/2668

I released a patch for compressing the facts while they are transmitted. This is not the correct fix but a more like a workaround.

It seems the patch has been accepted for 0.25.x.

The patch is in the tickets/0.25/2668 branch in my github repository: http://github.com/masterzen/puppet/tree/tickets/0.25.x/2668

#11 Updated by James Turnbull about 5 years ago

  • Status changed from Ready For Checkin to Closed
  • Target version changed from 0.25.2 to 0.25.1

Pushed in commit:e8bce7a6c3d0941fb3b461d2f0487b3f249ff5f1 in branch 0.25.x

#12 Updated by Lluís Gili about 4 years ago

  • Status changed from Closed to Re-opened
  • Target version deleted (0.25.1)

When the facts grow, this problem reappears, sorry to re-open We have some facts really long (DSA public keys) that are blocking puppetruns.

#13 Updated by James Turnbull about 4 years ago

  • Status changed from Re-opened to Needs More Information

What version are you running?

#14 Updated by Lluís Gili about 4 years ago

master and agent are version 0.25.4 both

#15 Updated by James Turnbull about 4 years ago

  • Affected Puppet version changed from 0.25.0 to 0.25.4

#16 Updated by James Turnbull almost 4 years ago

  • Status changed from Needs More Information to Duplicate

Added Bug #6117 to revisit this issue since the original issue had been addressed with the b64+gzip patch.

#17 Updated by Mark Stanislav almost 4 years ago

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

#18 Updated by James Turnbull almost 4 years ago

Mark – do you mean 2.6.4? Or 0.25.4?

#19 Updated by Bram Mertens about 2 years ago

I’ve run into the same problem: * puppet master running on fedora 17: version 2.7.18-1.fc17 * puppet client running on CentOS6 (package from EPEL6): version 2.6.17-2.el6

# facter |wc 
dnsdomainname: Unknown host
62     202    2518

FYI puppet client 2.7.18-1.fc17 running on the same fedora 17 machine as the master works fine

Also available in: Atom PDF