Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

2016-08-02 10:48 GMT+02:00 Yann Ylavic : > On Tue, Aug 2, 2016 at 8:22 AM, Luca Toscano > wrote: > > > > So IIUC you are saying to always done+break in the 304 use case (to avoid > > reading from the connection again), and then detect the response in

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

On Tue, Aug 2, 2016 at 2:59 PM, Luca Toscano wrote: > > 2016-08-02 10:48 GMT+02:00 Yann Ylavic : >> >> What I don't know is whether or not we need to read AP_FCGI_END_REQUEST >> anyway? >> If that's the case, we should indeed not break until then, and

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

2016-08-02 15:23 GMT+02:00 Yann Ylavic : > On Tue, Aug 2, 2016 at 2:59 PM, Luca Toscano > wrote: > > > > 2016-08-02 10:48 GMT+02:00 Yann Ylavic : > >> > >> What I don't know is whether or not we need to read AP_FCGI_END_REQUEST

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

On Tue, Aug 2, 2016 at 4:07 PM, Luca Toscano wrote: > > 2016-08-02 15:23 GMT+02:00 Yann Ylavic : >> >> If that's correct, we indeed shouldn't break until we got >> AP_FCGI_END_REQUEST, so that we can reuse the connection when all goes >> well. > >

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

On Tue, Aug 2, 2016 at 6:58 PM, Luca Toscano wrote: > > 2016-08-02 17:54 GMT+02:00 Yann Ylavic : >> >> On Tue, Aug 2, 2016 at 5:05 PM, Yann Ylavic wrote: >> >> Actually, unless we want to check/enforce that a Status 304 (as >>

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

On Tue, Aug 2, 2016 at 5:05 PM, Yann Ylavic wrote: > > So we need to detect whether the 304 is a CGI Status or ours. > It seems that in the former case r->status is 304, whereas in the > latter case this is the local variable 'status' only. > We could possibly set

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

2016-08-02 17:54 GMT+02:00 Yann Ylavic : > On Tue, Aug 2, 2016 at 5:05 PM, Yann Ylavic wrote: > > > > So we need to detect whether the 304 is a CGI Status or ours. > > It seems that in the former case r->status is 304, whereas in the > > latter case

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

To follow up on an IRC comment: I like performance improvements, but this is code that we've identified a large number of bugs/misfeatures in recently, and I think there are plans for further changes soon. Performance improvements tend to fragment things and make later refactoring difficult,

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

2016-08-02 19:18 GMT+02:00 Jacob Champion : > To follow up on an IRC comment: > > I like performance improvements, but this is code that we've identified a > large number of bugs/misfeatures in recently, and I think there are plans > for further changes soon. Performance

Re: Anyone using CLion ?

On Mon, Aug 1, 2016 at 7:24 AM, Jim Jagielski wrote: > CLion is a C IDE built around cmake. I thought I'd try using it > w/ trunk but have had numerous issues, likely because our cmake > implementation is a work-in-progress. Anyone have success in > using CLion on httpd or, in

Re: 2.4.24 soon?

On Fri, Jul 22, 2016 at 5:10 AM, Jim Jagielski wrote: > I think we should look into other stuff we could fold in in > the short term. > Seems overdue for us to fold the HTTP_STRICT logic back into 2.4 and 2.2 before we tag and roll again. It seems pretty odd not to follow

Re: 2.4.24 soon?

On Aug 2, 2016 11:58 AM, "William A Rowe Jr" wrote: > > On Fri, Jul 22, 2016 at 5:10 AM, Jim Jagielski wrote: >> >> I think we should look into other stuff we could fold in in >> the short term. > > > Seems overdue for us to fold the HTTP_STRICT logic back

Re: 2.4.24 soon?

On 08/02/2016 11:12 AM, William A Rowe Jr wrote: One additional thought... On 2.2 and 2.4 I see this change as entirely opt-in, no disruption to a user performing a subversion upgrade. On 2.6/3.0 I'd want us to seriously consider changing the out-of-the-box default to strict parsing. +1. (I

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

Hi Yann, thanks a lot for the review, answer inline: 2016-08-02 1:03 GMT+02:00 Yann Ylavic : > On Mon, Aug 1, 2016 at 12:55 PM, wrote: > > > > Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c > > URL: >

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

2016-08-02 8:22 GMT+02:00 Luca Toscano : > Hi Yann, > > thanks a lot for the review, answer inline: > > 2016-08-02 1:03 GMT+02:00 Yann Ylavic : > >> On Mon, Aug 1, 2016 at 12:55 PM, wrote: >> > >> > Modified:

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

2016-08-01 21:13 GMT+02:00 Jacob Champion > > > As stated above, this is not my first choice -- but I wouldn't oppose it > if that's what the consensus comes to. > > else if (!ap_cstr_casecmp(w, "Last-Modified")) { >> -apr_time_t parsed_date =

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

On Tue, Aug 2, 2016 at 8:22 AM, Luca Toscano wrote: > > So IIUC you are saying to always done+break in the 304 use case (to avoid > reading from the connection again), and then detect the response in another > place. Yes, any following data is for the next request. >