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