HTTP 414 errors on URLs only 256 characters long

[Tim_Wakeling]

Hi - any thoughts on this little puzzler?

My Linux (CentOS) server with Plesk 12 is giving HTTP 414 errors ("URL too long") in response to URLs which are over 256 characters in length. They happen to include a GET variable in the query string which accounts for most of this length, and if I shorten it manually, it works. But I can't change the script to submit a shorter URL or send it by POST, because it comes from an external payment processing server which I don't control.

Adding the following lines to my /etc/httpd/conf/httpd.conf file and restarting Apache does not work:
LimitRequestLine 8190
LimitRequestFieldSize 8190

The URLs I'm trying to use are well short of 8190 bytes; they are around 800 characters long.

Is this something that Plesk affects / can control? Is there a way to see what the current maximum setting for URL length is, and to change it?

My hosting company have drawn a blank and asked me to contact you instead... I'm tearing my hair out so any help would be gratefully received!

Tim

 

[UFHH01]

Did you as well edit the lines in your domain - specific config file under: "/var/www/vhosts/system/YOURDOMAIN.com/conf/httpd.conf" ?

 

[Tim_Wakeling]

Thanks for the thought, but sadly not the answer. The file you mention says this:

#ATTENTION!
#
#DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
#SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED.
#IF YOU REQUIRE TO APPLY CUSTOM MODIFICATIONS, PERFORM THEM IN THE FOLLOWING FILES:
#/var/www/vhosts/system/mydomain.com/conf/vhost.conf
#/var/www/vhosts/system/mydomain.com/conf/vhost_ssl.conf

And when I look for vhost.conf and vhost_ssl.conf they are both absent. So I can only assume the settings from the primary conf file are being used...

Tim

 

[Tim_Wakeling]

By the way, I also have these lines:

Alias /error_docs /var/www/vhosts/mydomain.com/error_docs
ErrorDocument 414 /error_docs/request_uri_too_long.html

And they are being ignored. I am not getting an HTML page as an error; just a white screen and an entry in the log file. If I could only display a meaningful message to users in this error situation, that would at least be something!

Tim

 

[UFHH01]

The commands:

/usr/local/psa/admin/sbin/httpdmng --reconfigure-all
or
/usr/local/psa/admin/sbin/httpdmng --reconfigure-domain YOURDOMAIN.COM​

... should solve your problem, if you have missing files. Your assume is partly incorrect. If there are no "vhost.conf" or "vhost_ssl.conf" - files, then there is simply no modification and only the domain specific "httpd.conf" is used. You have as well the option to modify additional vhost - configuration over the Plesk Panel:

Websites & Domains > <domain_name> > Web Server Settings​

The command "/usr/local/psa/bin/repair --restore-vhosts-permissions" repairs wrong file/folder - permissions, which could exist and therefore aren't served correctly by your webserver.

 

[Tim_Wakeling]

Thanks for your help ... you had me hopeful there for a moment! However I checked the Web Server Settings in Panel, and the two "LimitRequest" lines mentioned above are definitely present in the "Additional directives for HTTP" and "Additional directives for HTTPS" boxes. They are also present in vhost.conf and vhost_ssl.conf files in the domain's system folder you mentioned.

Having checked all this, I ran your commands to "reconfigure all" and "restore vhosts permissions", which completed successfully, but the server still rejects URLs longer than 256 characters.

Sorry we're not there yet. What else can I try? Is there no way to see what the server is actually doing and which configuration setting it is applying for a particular request?

 

[UFHH01]

The hierarchy for the configurations is:

Default webserver settings - Service Plan webserver settings - Website webserver settings​

Each previous setting gets overwritten by any upcoming setting, which means, if you set up something in the default value, a different value in the service plan overwrites this setting. The same with website settings = if you set up something different here, than in the default or service plan - settings, it gets overwritten by the setting from the website webserver settings. The only reason why this might not work as expected is, that you have configurations failures, either with permissions, or by misstyped values, which can not be initiated because of this reasons.

Another reason might be, that you choosed nginx to work with apache as well and didn't configure nginx the same way. If nginx should serve php - files they will never been served based on the apache configuration.

 

[Tim_Wakeling]

Thanks for the clarification; I will check the heirarchy but I suspect this is how it is set up. It seems to be.

I do wonder whether nginx is overriding things somehow although I was under the impression that Apache was serving the PHP. Do you know how I can check what nginx's status is and what limits it has set for URL length?

Tim

 

[UFHH01]

These are the standard nginx definitions:

client_header_buffer_size 1k;
large_client_header_buffers 4 4k;

For nginx you could use this ( again, you could use the additional webserver settings for the domain instead of using this in the global configuration! ):

if ($request_uri ~ '.{1024,}') {
return 414;
}

This limits the URL to 1024 characters, which really should be more than sufficient.

 

[Tim_Wakeling]

Thanks; just checked nginx configuration and it was set to

client_header_buffer_size 2k;
large_client_header_buffers 4 8k;

I tried increasing it to

client_header_buffer_size 8k;
large_client_header_buffers 4 16k;

just temporarily and restarted nginx, apache and httpd to see whether it solved it, but it didn't. Still failing with a 414 error on URLs of over 256 characters. So I returned nginx to the 1k / 4k default settings.

I noticed one more thing: sending a long parameter to a normal HTML page rather than a PHP script does not fail with a 414. The server only seems to reject long URLs when they are being sent to PHP scripts. I can't see any clues in php_info() about a URL limit, and although I read that suhosin sometimes imposes one, suhosin does not appear to be installed...

Tim

 

[Tim_Wakeling]

OK, I have solved the problem! Well, sort of.

I discovered that if I referenced a specific PHP script file instead of a "pretty URL", it worked. So this fails with a 414:
http://mydomain.com/?param=20580c13...cbd131ed9949120ff629b4c2ad75e340d7b00e997a151

But this succeeds:
http://mydomain.com/test.php?param=...cbd131ed9949120ff629b4c2ad75e340d7b00e997a151

That doesn't really answer the question of why it failed, but it'll do for me. I can divert the requests to a URL with a PHP extension in this case. Still a puzzle, but perhaps now one for another day...

Many thanks for your advice though!

Tim

 

[UFHH01]

I would like to mention, that using nginx and FastCGI often requires some specific location definitions. There are some standard configurations at your domain - specific nginx.conf - file, but these standards will certainly fail, if you use non - existing URLs, or have missing location - definitions. An URL like the first example is not a valid URL at all, so you will be redirected ( depending on your definitions ) and that will increase your provided example URL again ( for example to: http://mydomain.com/?param=20580c13...cbd131ed9949120ff629b4c2ad75e340d7b00e997a151 ( please copy and paste to see the full redirect URL!!! ) and as you can see, this more than doubles the characters of the URL! ) Please be sure, that your definitions are valid and working, to avoid this.

 

[Tim_Wakeling]

I see. In this case that's OK. Often, however, I do need to pass GET variables to pages whose URLs are pretty WordPress permalinks ending in "/", not ".php". I'll have to do some more reading on the subject.

 

[UFHH01]

That's why the use of rewrites or specific location definitions might help you:

For example:
rewrite ^/(.*).html$ /index.php?params=$1 last;​

... will rewrite HTML - files to index.php?params= +their value.

 

[Tim_Wakeling]

I'll see what I can do - thank you!