Hey Graham,

thanks for your effort and sorry that I didn't have time to work on
this the last 3 days.

kind regards
Marcel

On Jan 3, 11:44 am, "Graham Dumpleton" <[email protected]>
wrote:
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to