Re: LimitRequestBody + ErrorDocument 413 only works for Opera Browser
Graham Dumpleton
100-continue feature of HTTP/1.1. That may in part be the reason. I
would have to do some testing to say more.
BTW, please use the mod_wsgi mailing list of Google Groups, to which I
have cc'd this for any followups.
Graham
2009/6/20 Robin <robi...@gmail.com>:
> Hello,
>
> Will you be so kind in helping me with some file limit problem in Django?
>
> I'm using apache2.2 with WSGI as you seem to recommend so much on the net.
>
> I tried to use:
> LimitRequestBody 2100000
> ErrorDocument 413 http://www.autoritel.com/413/
>
> In order to give my own custom FILE_TOO_LARGE error page.
>
> My custom error page only shows correctly for Opera only though.
>
> Firefox 3 gives:
> Connection Interrupted
> The document contains no data.
> The network link was interrupted while negotiating a connection. Please try
> again.
>
> Internet Explorer 6 gives:
> The page cannot be displayed
> The page you are looking for is currently unavailable. The Web site might
> be experiencing technical difficulties, or you may need to adjust your
> browser settings.
>
> Please try the following:
> ...
>
> Attached in this email are screenshots of these 2 error pages.
>
> Thank you if you have time to help. I couldn't find anything on it on
> Google.
>
> Below are my apache configuration files.
>
> Robin
>
>
> ------/etc/apache2/httpd.conf-----------------------------------------
> LoadModule wsgi_module modules/mod_wsgi.so
>
> Include "/var/www/autoritel/apache/apache_django_wsgi.conf"
>
>
> ------/var/www/autoritel/apache/apache_django_wsgi.conf---------------
>
> WSGIDaemonProcess site-1 user=www-data group=www-data threads=25
> WSGIProcessGroup site-1
>
> <Directory "/var/www/autoritel/media">
> Order allow,deny
> Options Indexes
> Allow from all
> IndexOptions FancyIndexing
> </Directory>
>
> <Directory "/var/www/autoritel/apache">
> Order deny,allow
> Allow from all
> </Directory>
>
>
> <VirtualHost *:80>
> #about 2mb
> LimitRequestBody 2100000
> ErrorDocument 413 http://www.autoritel.com/413/
>
> ErrorLog /var/log/apache2/error.autoritel.log
> CustomLog /var/log/apache2/access.autoritel.log combined
>
> Alias /media/ "/var/www/autoritel/media/"
>
> WSGIScriptAlias / "/var/www/autoritel/apache/autoritel.wsgi"
> </VirtualHost>
robin
can do on Apache to get ErrorDocument to show (except in Opera)?
Is there a 'non-proper' way to get IE6 and Firefox 3 to show the
ErrorDocument?
On Jun 20, 1:48 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> 100-continue feature of HTTP/1.1. That may in part be the reason. I
> would have to do some testing to say more.
>
> BTW, please use the mod_wsgi mailing list of Google Groups, to which I
> have cc'd this for any followups.
>
> Graham
>
>
>
> > Hello,
>
> > Will you be so kind in helping me with some file limit problem in Django?
>
> > I'm using apache2.2 with WSGI as you seem to recommend so much on the net.
>
> > I tried to use:
> > LimitRequestBody 2100000
Graham Dumpleton
> Are you saying that this is a browser problem and there is nothing I
> can do on Apache to get ErrorDocument to show (except in Opera)?
Drop your LimitRequestBody to a small value, eg., 50000, and test with
a post size just a little bit over that and see if you get your proper
error response page.
What is probably happening with your much larger posts is that the web
client hasn't finished the sending of the data before the web server
writes back its response and then closes the connection. The client is
seeing an error on trying to write the data because of the socket
being closed and instead of giving up on trying to send data and see
if there is a response, is just generating an error that connection
has died.
The test above if done with post content size which is less that
socket buffer size, should show if it works for case where web client
was able to send all post content and so had been able to shift to
looking for a response. This will show that web server is doing
everything it should correctly and that the problem is with the web
client and how it handles socket connection being closed before all
data sent but where there could have been a valid response waiting to
be read.
Graham
robin
> a post size just a little bit over that and see if you get your proper
> error response page.
and returns the correct ErrorDocument.
> The test above if done with post content size which is less that
> socket buffer size, should show if it works for case where web client
> was able to send all post content and so had been able to shift to
> looking for a response.
> This will show that web server is doing
> everything it should correctly and that the problem is with the web
> client and how it handles socket connection being closed before all
> data sent but where there could have been a valid response waiting to
> be read.
So any suggestion or workaround if I insist on giving LimitRequestBody
a large number?
How do other large sites do it then (Flickr, Facebook)?
Javascript?
Robin
Graham Dumpleton
>
>> Drop your LimitRequestBody to a small value, eg., 50000, and test with
>> a post size just a little bit over that and see if you get your proper
>> error response page.
>
> OK done, if I upload an image just over 50kb, both IE and Firefox work
> and returns the correct ErrorDocument.
>
>> The test above if done with post content size which is less that
>> socket buffer size, should show if it works for case where web client
>> was able to send all post content and so had been able to shift to
>> looking for a response.
>
> Not sure what socket buffer size is.
On MacOS X Leopard it is 131070 bytes.
>>> import socket
>>> s=socket.socket()
>>> s.getsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF)
131070
How much you can send before blocking is possibly going to depend on a
lot of things though, including settings of client and intermediary
network.
>> This will show that web server is doing
>> everything it should correctly and that the problem is with the web
>> client and how it handles socket connection being closed before all
>> data sent but where there could have been a valid response waiting to
>> be read.
>
> I guess it seems to be a browser problem then.
>
> So any suggestion or workaround if I insist on giving LimitRequestBody
> a large number?
> How do other large sites do it then (Flickr, Facebook)?
> Javascript?
Sorry, don't know. I didn't actually know the browsers didn't do it
properly for large posts to begin with.
Graham