Apache Bad Request

[charlesh]

I've got a site that has a large form that I split up into several pages. I'm using php sessions to gather data as the pages go along. The trouble is, though, that there are many many fields. After I get about 4 pages in deep out of 5, I get this error:
Bad Request

Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.

I'm also using cookies to keep track of data, so that if a person returns, they will be able to have all the fields pre-filled. Suffice to say, quite a large sum of cookie strings. I'm serializing all the data, so there aren't many cookies, but quite a bit of data in each cookie.

Is there a setting on the server to adjust to increase the size or another way around this issue?

Thanks,

[charlesh]

Nevermind. I was corrupting the cookie myself!

[charlesh]

Well, turns out that it wasn't that. I really think that it is a size thing, since I get this error on page 4/5, but if I start on page 3/5 without adding all those values to the session variable, there isn't a problem.

Is there a way to increase this size on Apache?

[Dmitriy]

Yes, it is. To increase request size in Apache, add directive LimitRequestFieldSize to the configuration file. Default value is 8190 bytes. To increase it 2 times add
LimitRequestFieldSize 16380. Don't know if it will work from .htaccess. Probably not, so this is the question to support team, but.... I'd strongly suggest you not adding as much data to the cookies as your web-site clients might experience a whole lot of other problems with large cookies. Why don't simply save some pseudo-random hash to clients machine and all the data in your DB? This is also has better security than cookies.

[rlhanson]

I'd strongly suggest you not adding as much data to the cookies as your web-site clients might experience a whole lot of other problems with large cookies.

What kind of problems Dmitriy?

[Dmitriy]

At least 2 comes into my mind:
- some browsers have its own limits of cookie size (old versions of Mozilla and some *nix browsers)
- IE6 and 7 has a known problem of cookies not saving when they run out of Temporary Internet Files storage limit
Chances of experiencing these might be low, but if the form is vital, like service order form and saving form state is critical - it would be wise to spend more time on development than debug 'strange' bug later, IMO.

[rlhanson]

Would a system shut down with an error of Kernel Dump Size be related to extra large cookies?
It said something about page size...

[Dmitriy]

Can't say exactly. The dump is saved when web-server thread crashes, but 400 error (the one that fires when the request too large) is not the one that makes server crash.

If you need to debug some script that results in creating memory dump, why don't you log $_REQUEST variable at the first few lines of your script? Just don't make it on highly loaded web-sites

[rlhanson]

Thanks Dmitriy - I'll pass that comment on to Charles who would know what your talking about.

I was testing the form, got the bad request notice, logged on to respond here and got the stop error and memory dump thing.

This form is interacting with another server which has an intranet of sorts that my client works with. Basically the application, when submitted goes into their program they use for property management.
What we ran into, is if the captcha code was input incorrectly (at the very end of an excruciating form) the form processor reloaded the form page and everything entered was gone. Charles has gotten the form to break into multiple pages with a quick save feature which is what he mentions at the beginning of the thread.

I think he's using AJAX and php sessions combined to allow the user to come back within 30 days and continue with the application. I'll let Charles think this out and get out of your guys' way...

Thanks again Dmitriy.

[Dmitriy]

I see. I'd suggest to make form submit via AJAX, so you don't have to reload anything if something fails - CAPTCHA or any other field that can't be validated on the client side.

Another thing if you want to save the form state for some time... There are few places we had done that and one of them is GlowHost order form. The main rule to follow - client machine must work only with ids and not whole set of different data types. This might look silly, but in the end it pays back