On Wed, Apr 16, 2008 at 10:53:38AM +0100, William A. Rowe, Jr. wrote: > Ray Van Dolson wrote: >> Hi all, running into this on an old Apache 2.0.46 installation >> (actually httpd-2.0.46-70.ent from RHEL 3 Update 9). >> >> When a user attempts to upload a large file it's exceeding the >> LimitRequestBody size and Apache returns a 413 error. It appears >> however that the browser (IE6 and FireFox 2.x in this case) do not >> display the 413 message and instead show an error as if the connection >> has been reset. >> >> Upon examination of the packet stream I do see the 413 message reaching >> the client, but after that the server immediately sends RST,ACK packets >> to tell the client to quit trying to send data. I'm guessing this is >> triggering the browser to just abort instead of showin the 413 error >> page. >> >> Is this something that could be handled differently by Apache > > yes - Apache could consume the entire message body. Issue is that you > likely limited request bodies for a good reason (e.g. traffic limiting) > so there is no desire to do this. Yeah, exactly. :) Well, it's clear the browser gets the 413 packet, I just wish it would do something with it instead of acting on the RST's. > Could we perhaps consume and discard an additional LimitRequestBody amount > of traffic before our read-close? Probably it's worth a hack to find out > if this helps the client any. In my case this probably wouldn't as my LimitRequestBody is set to a very large value. I'd like for the client to being attempting an upload that is "too large" and for Apache to yell "Stop!" after it gets the Content-Length header and then have the browser actually acknowledge and display the error... would it work to have Apache consume a "bit more" of the data before aborting the connection? Probably not. Ray --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx