2

I'm trying to add new functionality to my site which involves passing a whole bunch of parameters (could be hundreds of parameters) all encoded in base64 format. When I attempt the new URL I get an error 403 (access denied).

I verified this to be a length issue because I then tried accessing the same domain but instead of base64 code, I used numbers after the URL and I still get the same error.

If you feel like scrolling across, you'll see the URL I try to access:

http://example.com/1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

I was looking through my apache configuration files and the only thing that stood out which doesn't make sense here is this:

LimitRequestFieldSize 8200
LimitRequestLine 8200

I say it doesn't make sense because I set the values to 8200 which I think means accept up to 8200 characters in the URL (not 400).

Is there a setting I can use in apache to fix this problem, because I know its an apache issue but I'm not sure which setting to fix.

| improve this question | |
  • Check out the first answer here: stackoverflow.com/questions/1289585/… – closetnoc Dec 31 '15 at 2:14
  • But my limit is set to 8200 bytes which is more than default – Mike -- No longer here Dec 31 '15 at 6:01
  • Does the Apache error log give you a clue as to the cause? – Tim Fountain Dec 31 '15 at 12:33
  • I thought is was interesting and informational. Are you hitting the 8190 or 8177 limit without realizing it?? Sometimes with Apache a restart will not do. You need a cold start - just in case this is one of those cases. It may be that your configuration changes are not taking effect with a simple restart. (or stop / start - you may need a reboot) – closetnoc Dec 31 '15 at 16:29
  • Apache claims I'm trying to access a folder with that length and the underlying file system (linux ext4) claims the name is too long. – Mike -- No longer here Jan 1 '16 at 0:45
1

Based on both your question as well as your follow up comments it would appear to me that the issue is to do with your rewrite rules not taking effect. You mention that the long string of numbers is a base64 encoded string of a large range of parameters, from this statement I make the assumption that the base 64 encoded string is not in fact a folder you are trying to access however from your final comment made Jan 1 at 0:45 you state

Apache claims I'm trying to access a folder with that length and the underlying file system (linux ext4) claims the name is too long)

From this comment it would indicate to me that Apache is not rewriting the URL so that the base64 encoded parameters are sent to a script to process and is instead treating it as a directory to access, in which case the string is in fact too long for a directory or file name in the ext4 filesystem. Take a look at your rewrite rules and make sure that the bbase64 encoded string is rewritten as a parameter to a script file.

| improve this answer | |
  • The base64 is processed by my PHP script as well as javascript. my apache configuration settings do not decode nor encode base64 values. I bet its a filesystem issue – Mike -- No longer here Jul 7 '16 at 1:02
  • The only reason why your file system would have anything to do with that base64 string is if Apache was trying to access a directory named that instead of passing it to a script to process. If it was rewritten to a script to process then Apache would not even attempt to do any file system process with it. I imagine you have some rewrite rule which states that if it isn't a real directory then process it through PHP, this could be the culprit as it is still trying to check if it is a real directory first. – Chris Rutherfurd Jul 7 '16 at 1:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.