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] 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]. > 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.
