Hmm, even if it was keeping the connection alive, doing it by withholding the final chunk of a response seems like an odd way to go about it. But yeah could be a bug there.
I've actually already been disabling 100-continue with curl. It was causing me some problems awhile back. So hopefully nothing related to that. I'll try to debug within modwsgi and see what is going on. On Saturday, February 22, 2014 8:16:25 PM UTC-8, Graham Dumpleton wrote: > > The handling of the connection back to the client is handled by Apache. > > In the case of the web application returning a 401, even if the HTTP > client were sending a header of: > > Expect: 100-continue > > then Apache should simply return the error response and then immediately > close both the input and output sides of the connection. It should not > delay anything. > > That is, it shouldn't maintain the connection and attempt to keep it alive > for HTTP 1.1 pipelining as it is only meant to do that for a successful > response and not 4XX or 5XX responses. > > Because this is all up to Apache, can't see that mod_wsgi would be causing > an issue. > > Only thing I can thing of is whether your 401 response actually has a > content length. Not having a content length shouldn't prevent Apache > closing the connection though as mod_wsgi would have already said that the > request was over and that there couldn't be any more data. > > All I can suggest is try: > > > http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response > > and see if you can see timing of when things get output from the Django > application. > > Beyond that, force curl not to try and use 100-continue, as I believe it > may try to do by default. See: > > > http://mustalikachwala.blogspot.com.au/2011/06/http11-100-continue-while-posting-data.html > > From memory curl does handle properly getting an error rather than a 100 > as first thing, but maybe for some reason the 100-continue is causing > issues. > > Graham > > > On 23/02/2014, at 2:59 PM, [email protected] <javascript:> wrote: > > OS binary. Using Ubuntu 12.10 with apache2 2.2.22-6ubuntu2.3 and > libapache2-mod-wsgi 3.4-0ubuntu1. > > On Saturday, February 22, 2014 7:45:28 PM UTC-8, Graham Dumpleton wrote: >> >> What version of Apache are you using? >> >> Is the mod_wsgi compiled from source code or an OS binary package? >> >> Graham >> >> On 23/02/2014, at 2:22 PM, [email protected] wrote: >> >> Hi Graham, >> >> Thanks for the quick reply. I'm using embedded mode. >> >> Timeout 300 >> KeepAlive On >> KeepAliveTimeout 5 >> >> The 401 is being generated by my Django app. >> >> On Saturday, February 22, 2014 7:09:38 PM UTC-8, Graham Dumpleton wrote: >>> >>> Are you using embedded mode or daemon mode of mod_wsgi? If you are not >>> sure, supply the mod_wsgi directives you are using to setup your >>> application. >>> >>> Also, what have you set the following directives to in Apache. >>> >>> Timeout >>> KeepAlive >>> KeepAliveTimeout >>> >>> Finally,who is generating the 401? Apache or your Django application. >>> >>> Graham >>> >>> On 23/02/2014, at 1:30 PM, [email protected] wrote: >>> >>> Hi, >>> >>> I'm using modwsgi version 3.4 with Apache and Django. I've observed that >>> if the Django app responds to a POST request before the body of the request >>> has been received, then if the client also stops sending the body as a >>> result of this early reply, then the server will delay finishing the >>> response for 10 seconds. This is reproducible with curl, which will stop >>> sending the request body the moment an error response is received. >>> >>> I'm not sure yet if this is a bug in modwsgi. It could be a bug in >>> Apache or Django, too. I've already discussed the matter on the curl >>> mailing list and have ruled out the bug being in curl. I'm hoping someone >>> on this list can provide me with direction about where to go from here. >>> >>> The flow in detail: >>> >>> 1) Curl sends POST request to server, with small body (< 100 bytes). >>> 2) Server responds with 401 Unauthorized, with response body >>> "Unauthorized\n" and chunked encoding. >>> 3) Curl stops sending the request body. For such a small body to begin >>> with, I believe this means it has not sent any of the body at all. >>> 4) Curl receives the response body. >>> 5) 10 seconds later, Curl receives the final chunk. I've confirmed with >>> tcpdump that the server is indeed withholding this packet until after the >>> delay. >>> >>> My guess is that there's a timeout within the server stack waiting for >>> the rest of the request body, even though the response has already been >>> sent. This is not reproducible against Apache in file-serving mode, as it >>> seems to always read the entire request body. Even if I POST a 10MB file to >>> a non-existent file, Apache will read the whole thing before responding >>> with 404. I think the bug is in modwsgi or Django, then, and so here I am. >>> :) >>> >>> Maybe the 10 seconds is a hint about where the issue could be? >>> >>> Justin >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "modwsgi" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/modwsgi. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/modwsgi. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/groups/opt_out.
