2009/1/3 Graham Dumpleton <[email protected]>: > 2009/1/3 Graham Dumpleton <[email protected]>: >> 2008/12/31 Graham Dumpleton <[email protected]>: >>> BTW, an important distinction is that Opera is expecting a >>> 100-continue response before sending actual data. Apache stuffs up >>> 100-continue processing and mod_wsgi tries to workaround its mistake. >>> >>> What version of Apache are you using, and does the same code work when >>> run in embedded mode of mod_wsgi? >> >> The issue here is definitely with the 100-continue feature. >> >> Opera is the only browser I know of which tries to use this feature, >> but it only does so when post data is greater than 10KB in size. >> >> For reasons I don't understand yet, Apache is returning an end of >> stream marker on first read of bucket chain when trying to read input >> when proxying it across to daemon process. I saw this previously with >> 'curl' and although tried to work it out a couple of times, hadn't as >> yet. What I didn't understand was that if I did a much simpler test of >> 100-continue support using telnet against http port, it worked fine. >> Since Opera seems also to trigger issue, it must be something to do >> with all the extra headers that curl and Opera pass in the request. >> Something in there is causing Apache to do the wrong thing. >> >> What I also don't understand is that the code used to read the bucket >> chain for input when proxying is basically the same as is used in >> mod_cgi and mod_cgid . Thus any issue in Apache itself if it exists >> would have to affect CGI scripts as well. >> >> I will go back and do some more digging now that know it isn't just an >> issue with curl. > > I finally worked it out. Make code change as below: > > Index: mod_wsgi.c > =================================================================== > --- mod_wsgi.c (revision 1140) > +++ mod_wsgi.c (working copy) > @@ -9417,6 +9417,14 @@ > } > } > > + /* > + * Need to reset request status value to HTTP_OK else it > + * screws up HTTP input filter when processing a POST > + * request with 100-continue requirement. > + */ > + > + r->status = HTTP_OK; > + > /* Transfer any request content which was provided. */ > > seen_eos = 0; > > Note that line numbers may differ slightly from mod_wsgi 2.3 as doing > this change in 2.4 branch and it has other changes already. > > The problem is that there is a really stupid test in HTTP input filter > in Apache which says: > > /* Since we're about to read data, send 100-Continue if needed. > * Only valid on chunked and C-L bodies where the C-L is > 0. */ > if ((ctx->state == BODY_CHUNK || > (ctx->state == BODY_LENGTH && ctx->remaining > 0)) && > f->r->expecting_100 && f->r->proto_num >= HTTP_VERSION(1,1) && > !(f->r->eos_sent || f->r->bytes_sent)) { > if (!ap_is_HTTP_SUCCESS(f->r->status)) { > ctx->state = BODY_NONE; > ctx->eos_sent = 1; > } else { > char *tmp; > > tmp = apr_pstrcat(f->r->pool, AP_SERVER_PROTOCOL, " ", > ap_get_status_line(100), CRLF CRLF, NULL); > apr_brigade_cleanup(bb); > e = apr_bucket_pool_create(tmp, strlen(tmp), f->r->pool, > f->c->bucket_alloc); > APR_BRIGADE_INSERT_HEAD(bb, e); > e = apr_bucket_flush_create(f->c->bucket_alloc); > APR_BRIGADE_INSERT_TAIL(bb, e); > > ap_pass_brigade(f->c->output_filters, bb); > } > } > > For whatever reason, it checks ap_is_HTTP_SUCCESS(f->r->status). > > Problem is that the handshake done my mod_wsgi daemon mode to > determine if daemon process was going to restart, was changing status > value to 0. Thus it failed this test and input stream was returning > end of stream indicator rather than data.
The issue for this is: http://code.google.com/p/modwsgi/issues/detail?id=121 This has been fixed in mod_wsgi version 2.X (2.4) branch at revision r1149 and in mod_wsgi main development trunk (3.0) at revision 1151. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
