It works fine, except for when "1,2,3,4" turns into a string longer than 255 characters, Apache returns a "403 Forbidden".

There is no problem visiting foo.php?id=1,2,3,4 directly, even with a very long id string, however this isn't an option for me.

Is there some Apache or other setting I should tweak?

UPDATE: I turned RewriteLog on with RewriteLogLevel 9. With a short id string, I get several lines in my log file. But when the id string is greater than 255 chars., nothing is logged (seems as though mod_rewrite isn't even executing?).

Might this be a regex problem? Have you checked that the rewritten request is correct for strings longer than 255 characters? If not, perhaps you could post the pre- and post- rewrite requests.
–
tomjedrzMay 17 '10 at 16:58

3

Enable mod_rewrite's logging with RewriteLog and RewriteLogLevel so you can see what is being matched and how it's really being rewritten. I would guess that only 255 characters are being copied into $1, and that ends up being an id that the client isn't authorized to see, so Apache returns the 403. I haven't looked at the code, but it could be that Apache manipulates the backreference in a fixed 256-byte buffer (the 256th is reserved for the terminating NULL).
–
James SneeringerMay 17 '10 at 17:50

See update in question -- nothing is logged for long params
–
philfreoMay 17 '10 at 18:51

4 Answers
4

May be the max filename length is of 255 bytes and when apache or the mod_rewrite rule checks if the file exists an error is returned to apache by the operating system.

If you put some rule in your .htaccess file, It's too late to work around the problem. Apache will have already tried to stat the filename and thrown file system error '(36)File name too long', returning a 403 error.

Maybe you could change the URL pattern inside your app. to a max of 255 chars from slash to slash.

EDIT: look here for a detailed answer to this issue. I borrowed mine from there.

so, you're thinking maybe Apache is trying to stat the requested file regardless - I mean, that could be the only way to explain that the too long URL isn't even being picked up by the rewrite engine...
–
HorusKolMay 22 '10 at 9:04

Yes this is my idea, although I think that in general having so long urls and filenames should be avoided for a number of reasons. So the best advice I could think maybe is to change something in the URL pattern if the filename isn't already too long.
–
microspinoMay 22 '10 at 10:26

That makes sense, but nope, I'm not. I edited my question to include the .htaccess file in its entirety. Other ideas?
–
philfreoMay 17 '10 at 16:45

According to "Apache mod_rewrite Technical Details" at httpd.apache.org/docs/trunk/rewrite/tech.html "Although mod_rewrite rewrites URLs to URLs, URLs to filenames and even filenames to filenames, the API currently provides only a URL-to-filename hook.". So even though you are not hitting an actual file, maybe the URL to filename hook is hitting the OS resource limit?
–
Stefan LasiewskiMay 21 '10 at 23:53

Definitely an interesting question. Do you run mod_security and if so, tried without it? Perhaps it simply doesn't like long path names or long path names with unencoded commas in them? ^^

Though it instinctively feels more like a limit on the url path or at least individual segments of it or the underlying filesystem interpretation of it as GmonC wrote. That would also explain why the regular url with the long part in the query string works fine.

I think older ASP.NET used to have a request path limit of ~260 characters or something as well.

See update to question. And no, I don't see a mod_security file in /usr/include/apache2/ or /usr/lib/apache2/modules/ (but I do see mod_rewrite there) so I'm assuming it's not installed.
–
philfreoMay 17 '10 at 18:54