Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 3:51 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > Just did that, same thing. > I was using mpm_worker, but now tried mpm_event with same segfaults. FWIW, I'm running an (old) Debian 6.0.10 (squeeze, 64bit).

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 3:41 PM, Graham Leggett <minf...@sharp.fm> wrote: > On 6 Oct 2015, at 14:32, Yann Ylavic <ylavic@gmail.com> wrote: > >> So it seems to relate to the EOR bucket, first not being passed >> through, and second leading to a double-free or al

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On Thu, Oct 1, 2015 at 8:22 PM, Ruediger Pluem wrote: > > The issue is that openssl during the connect handshake to a clieent does not > tell httpd to flush. Hence the CLIENT_HELLO > remains in the core output filter buffer and openssl waits for the > SERVER_HELLO from the

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Sun, Oct 4, 2015 at 12:10 PM, wrote: > Author: minfrin > Date: Sun Oct 4 10:10:51 2015 > New Revision: 1706669 > > URL: http://svn.apache.org/viewvc?rev=1706669=rev > Log: > core: Extend support for asynchronous write completion from the > network filter to any connection

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 3:32 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > Just wanted to run the tests framework on trunk for a local change but > it seems that this commit (bisected to) makes many tests to segfault. Forgot to mention, same thing with follow up r1706670 applied.

Re: [Patch] Async write completion for the full connection filter stack

On Sun, Oct 4, 2015 at 1:40 PM, Graham Leggett wrote: > > The next bit of this is the ability to safely suspend a filter. > > A suspended filter is a filter that is waiting for some external event, a > callback of some kind, some timer that it might have set, and in the mean >

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On Tue, Oct 6, 2015 at 6:00 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Tue, Oct 6, 2015 at 5:44 PM, Joe Orton <jor...@redhat.com> wrote: >> >> Hence In the server case, it seems reasonable to rely on BIO_flush() >> being called at the "right"

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 5:53 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Tue, Oct 6, 2015 at 5:34 PM, Graham Leggett <minf...@sharp.fm> wrote: >> >> apr_bucket_simple_copy() looks wrong - in theory we should have a proper >> copy function that does the

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 6:29 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > all tests pass now. I spoke too soon... New segfault is in mod_substitute: Program terminated with signal 11, Segmentation fault. (gdb) bt #0 0x7fa02fbaec2b in allocator_free (allocator=0x1cedc

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On Tue, Oct 6, 2015 at 5:44 PM, Joe Orton wrote: > > Hence In the server case, it seems reasonable to rely on BIO_flush() > being called at the "right" times during the handshake. Modulo the odd > bug! > > But ssl/s3_clnt.c is not following that coding style at all, and it

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 7:00 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Tue, Oct 6, 2015 at 6:29 PM, Yann Ylavic <ylavic@gmail.com> wrote: >> >> all tests pass now. > > I spoke too soon... > > New segfault is in mod_substitute: Fixed in r1707091.

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 5:22 PM, Yann Ylavic <ylavic@gmail.com> wrote: > still the new filter should probably work > with the existing... s/new filter/new filter stack mechanism/

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

On Tue, Dec 8, 2015 at 3:07 AM, William A Rowe Jr wrote: >> >> The handler handling the first request has to read the body before the >> switch, eg. mod_proxy could forward the request without the client >> having switched to any other protocol. > > Whoa... First the handler

Re: Upgrade Summary

On Tue, Dec 8, 2015 at 11:54 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > > Am 08.12.2015 um 11:44 schrieb Yann Ylavic <ylavic@gmail.com>: >> >> On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing >>> >>> PS. Re 5: with change 1+4

Re: Upgrade Summary

On Tue, Dec 8, 2015 at 12:18 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Tue, Dec 8, 2015 at 11:54 AM, Stefan Eissing > <stefan.eiss...@greenbytes.de> wrote: >> >> Am 08.12.2015 um 11:44 schrieb Yann Ylavic <ylavic@gmail.com>: >>> >&g

Re: Upgrade Summary

On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing wrote: > Trying to summarize the status of the discussion and where the issues are > with the current Upgrade implementation. > > Clarified: > A. any 100 must be sent out *before* a 101 response > B. request bodies are

Re: Upgrade Summary

If so, for 2.4.18 we should probably backport Bill's proposal in STATUS (r1717816), so that OPTIONS works as in 2.4.16... On Tue, Dec 8, 2015 at 1:54 PM, Stefan Eissing wrote: > I see. Delta-V goodies. > > My proposal therefore is: > - keep the upgrade/protocol

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgradetls

On Tue, Dec 8, 2015 at 11:36 AM, Stefan Eissing wrote: > > I do not understand. How do you want to make pipelining requests and protocol > upgrades work together? I assume you talk about http pipelining where you > send a second request before you receive the

Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

On Tue, Dec 8, 2015 at 2:30 PM, wrote: > Author: ylavic > Date: Tue Dec 8 13:30:30 2015 > New Revision: 1718595 > > URL: http://svn.apache.org/viewvc?rev=1718595=rev > Log: > Comment about ap_request_has_body() check for Upgrade. > > Modified: >

Re: Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

On Tue, Dec 8, 2015 at 2:37 PM, Yann Ylavic <yla...@apache.org> wrote: > On Tue, Dec 8, 2015 at 2:30 PM, <yla...@apache.org> wrote: >> Author: ylavic >> Date: Tue Dec 8 13:30:30 2015 >> New Revision: 1718595 >> >> URL: http://svn.apache.org/vi

Re: Upgrade when !ap_request_has_body(r) only? (was: for 2.4.18)

On Tue, Dec 8, 2015 at 3:29 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Tue, Dec 8, 2015 at 7:37 AM, Yann Ylavic <yla...@apache.org> wrote: >> >> E.g. (on top of r1717816): > > The problem is that you are disabling *advertising* of the protocol based &

Re: Upgrade when !ap_request_has_body(r) only for 2.4.18? (was: svn commit: r1718595 - /httpd/httpd/branches/2.4.x/STATUS)

On Tue, Dec 8, 2015 at 3:17 PM, Jim Jagielski wrote: > My only suggestion is that instead of willy-nilly suggesting > patches that will be included in a release, that we actually take > time to think of the correct patch, to implement it and TEST against > it and only THEN have

Re: Protocol API @bug warnings for 2.4.18?

On Tue, Dec 8, 2015 at 4:31 PM, William A Rowe Jr wrote: > On Tue, Dec 8, 2015 at 9:21 AM, Stefan Eissing > wrote: >> >> >> > On Tue, Dec 8, 2015 at 8:34 AM, Stefan Eissing >> > wrote: >> > +1 for deferring any

Re: On the Upgrade request body limit

On Tue, Dec 8, 2015 at 11:43 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Tue, Dec 8, 2015 at 4:17 PM, Yann Ylavic <ylavic@gmail.com> wrote: >> >> Why any HTTP/1 response? If the Upgrade is accepted, ISTM that the >> response must be Upgraded,

Re: On the Upgrade request body limit

On Tue, Dec 8, 2015 at 11:00 PM, William A Rowe Jr wrote: > > Apache httpd server offers limits on the number > of incoming headers, the number of bytes in those headers, the number of > bytes in the request line, the length of the URI. The maximum request body > length.

Re: On the Upgrade request body limit

Jacob, On Tue, Dec 8, 2015 at 11:17 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > As I read the RFC, the simple(st) case is: > Request (upgrade: somespec) -> request body <- 101 (upgrade: somespec) > <- new protocol response or read Wouldn't that work for the

Re: On the Upgrade request body limit

On Tue, Dec 8, 2015 at 11:00 PM, William A Rowe Jr wrote: > > Define complex, robust. Request (upgrade: somespec) -> 100 continue -> > request body <- [ http/1.1 response | 101 - switching protocols <- new > protocol response ]. As I read the RFC, the simple(st) case is:

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

On Mon, Dec 7, 2015 at 5:38 PM, William A Rowe Jr wrote: > > https://tools.ietf.org/html/rfc7230#section-6.7 makes things more > interesting, it calls out that 101-continue and the request body read > precedes the 101-switching protocols. Not sure who decided that would be a

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

On Tue, Dec 8, 2015 at 1:07 AM, Yann Ylavic <ylavic@gmail.com> wrote: > > the body ought to be > set aside for any (relevant) TLS response (which needs the > handshake...). Hmm, no need to set aside, *unless* with must produce a response before the entire body (and the

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

On Tue, Dec 8, 2015 at 1:27 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Mon, Dec 7, 2015 at 6:15 PM, Yann Ylavic <ylavic@gmail.com> wrote: >> >> On Tue, Dec 8, 2015 at 1:07 AM, Yann Ylavic <ylavic@gmail.com> wrote: >> > >> > th

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

On Tue, Dec 8, 2015 at 1:13 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Mon, Dec 7, 2015 at 6:07 PM, Yann Ylavic <ylavic@gmail.com> wrote: >> >> The 100-continue case isn't a particular one IMHO, any Upgrade header >> would be informative, no

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

On Tue, Dec 8, 2015 at 1:58 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Mon, Dec 7, 2015 at 6:35 PM, Yann Ylavic <ylavic@gmail.com> wrote: >> >> The body of the first request is never Upgraded, so why would we read >> it using the Upgraded protocol

Re: [VOTE] Release Apache httpd 2.4.18 as GA

On Tue, Dec 8, 2015 at 9:38 PM, Jim Jagielski wrote: > > I'm calling a VOTE on releasing these as Apache httpd 2.4.18 GA. > > [X] +1: Good to go md5/sha1/pgp OK Tested on: * Debian 8.2 (Jessie) => All tests passed. * Debian 7.9 (Wheezy) => All tests passed. * Debian 6.0.10

Re: Upgrade Summary

On Fri, Dec 11, 2015 at 10:20 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > >> Am 11.12.2015 um 02:22 schrieb Yann Ylavic <ylavic@gmail.com>: >> >> On Thu, Dec 10, 2015 at 11:46 AM, Stefan Eissing >> <stefan.eiss...@greenbytes.de> wro

Re: svn commit: r1719403 - in /httpd/httpd/trunk: CHANGES modules/http2/h2_conn.c modules/http2/h2_h2.c modules/http2/h2_io.c modules/http2/h2_io.h modules/http2/h2_mplx.c modules/http2/h2_stream.c mo

Hi Stefan, On Fri, Dec 11, 2015 at 1:57 PM, wrote: > Author: icing > Date: Fri Dec 11 12:57:32 2015 > New Revision: 1719403 > > URL: http://svn.apache.org/viewvc?rev=1719403=rev > Log: > fixed window update on chunked uploads, moved handling of chunking to later > stage Is

Re: Upgrade Summary

Hi Jacob, On Fri, Dec 11, 2015 at 11:47 PM, Jacob Champion wrote: > > This is where we disagree, for the case of WebSocket and WebSocket alone. > RFC 6455 4.2.1: > >The client's opening handshake consists of the following parts. If >the server, while reading the

Re: [VOTE] Release Apache httpd 2.4.18 as GA

On Fri, Dec 11, 2015 at 9:21 PM, Rainer Jung wrote: > > - three compiler warning (2 regressions, one old) [] > modules/ssl/ssl_engine_kernel.c:414:22: warning: variable 'hssc' set > but not used [-Wunused-but-set-variable] This one is harmless ('hssc' redeclared

Re: [VOTE] Release Apache httpd 2.4.18 as GA

On Fri, Dec 11, 2015 at 10:57 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Fri, Dec 11, 2015 at 10:39 PM, Yann Ylavic <ylavic@gmail.com> wrote: >> On Fri, Dec 11, 2015 at 9:21 PM, Rainer Jung <rainer.j...@kippdata.de> wrote: >>> >>> - t

Re: Upgrade Summary

On Sat, Dec 12, 2015 at 12:41 AM, Yann Ylavic <ylavic@gmail.com> wrote: > Hi Jacob, > > On Fri, Dec 11, 2015 at 11:47 PM, Jacob Champion <champio...@gmail.com> wrote: >> >> This is where we disagree, for the case of WebSocket and WebSocket alone. >>

Re: [VOTE] Release Apache httpd 2.4.18 as GA

On Fri, Dec 11, 2015 at 10:39 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Fri, Dec 11, 2015 at 9:21 PM, Rainer Jung <rainer.j...@kippdata.de> wrote: >> >> - three compiler warning (2 regressions, one old) > [] >> modules/ssl/ssl_engine_kernel.c:

Re: missing semicolon

On Mon, Dec 14, 2015 at 6:03 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Mon, Dec 14, 2015 at 5:34 PM, Petr Gajdos <pgaj...@suse.cz> wrote: > > A simple (obvious) patch would be: Commited in http://svn.apache.org/r1719967 Proposed for backport to 2.4.19. Thanks again Petr.

Re: missing semicolon

On Mon, Dec 14, 2015 at 5:34 PM, Petr Gajdos wrote: > Hello Yann, > > http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c > > is missing semicolon in > > need_flush = !SSL_is_init_finished(outctx->filter_ctx->pssl) > > line. Relevant commit: > >

Re: Weird behaviour with mod_ssl and SSLCryptoDevice

Hi Jan, On Tue, Dec 15, 2015 at 12:51 PM, Jan Kaluža wrote: > > I think I've just fixed that in . I will > also propose that for 2.4.x and 2.2.x. Shouldn't we do the same for ecparams below? Regards, Yann.

Re: Upgrade Summary

On Thu, Dec 10, 2015 at 11:46 AM, Stefan Eissing wrote: > Given all the input on this thread, I arrive at the following pseudo code: Thanks for _compiling_ this thread, quite exhaustive :) I wonder if we could let each Protocols module hook wherever appropriate in

Re: Upgrade Summary

On Fri, Dec 11, 2015 at 2:22 AM, Yann Ylavic <ylavic@gmail.com> wrote: > > Here I would use ap_add_output_filter(switch_protocol_filter, r); with > switch_protocol_filter() which would flush out the 101 response (or > not) based on r->need_upgrade and r->curr

Re: svn commit: r1719403 - in /httpd/httpd/trunk: CHANGES modules/http2/h2_conn.c modules/http2/h2_h2.c modules/http2/h2_io.c modules/http2/h2_io.h modules/http2/h2_mplx.c modules/http2/h2_stream.c mo

On Fri, Dec 11, 2015 at 2:57 PM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > >> Am 11.12.2015 um 14:55 schrieb Yann Ylavic <ylavic@gmail.com>: >> >> Hi Stefan, >> >> On Fri, Dec 11, 2015 at 1:57 PM, <ic...@apache.org> wrote: &

Re: svn commit: r1722369 - in /httpd/httpd/trunk: ./ docs/manual/mod/ modules/http2/

On Wed, Dec 30, 2015 at 9:17 PM, Stefan Eissing wrote: > That feeds into the Grand Solution to make h2 workers part of the MPM. Not > sure how to approach that. How about calling apr_thread_join() in cleanup_zombies?

Re: svn commit: r1722899 - in /httpd/httpd/trunk: ./ modules/http2/

On Mon, Jan 4, 2016 at 4:30 PM, wrote: > Author: icing > Date: Mon Jan 4 15:30:36 2016 > New Revision: 1722899 > > URL: http://svn.apache.org/viewvc?rev=1722899=rev > Log: > reworked synching of session shutdown with worker threads, workers now stick > to a session until no

Re: Better ap_casecmpstr[n]?

On Tue, Dec 29, 2015 at 3:24 PM, Jim Jagielski wrote: > ping. > > Just a reminder that right now, trunk uses ap_casecmpstr[n](), > which can make some backport requests "problematic" due to > possible merge conflicts. I've just committed (in r1722150) more reverts of abusive

Re: Better ap_casecmpstr[n]?

On Tue, Dec 29, 2015 at 5:16 PM, Jim Jagielski wrote: > In a sep thread on dev@apr, OtherBill appears to be trying to > determine the "right" name for the APR impl... maube we should > wait to see what it's decided on there and we can follow > suit. OK, although we won't be

Re: Better ap_casecmpstr[n]?

On Tue, Dec 29, 2015 at 5:35 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> On Dec 29, 2015, at 11:28 AM, Yann Ylavic <ylavic@gmail.com> wrote: >> >> On Tue, Dec 29, 2015 at 5:16 PM, Jim Jagielski <j...@jagunet.com> wrote: >>> >>

Re: Weird behaviour with mod_ssl and SSLCryptoDevice

On Wed, Jan 6, 2016 at 12:28 PM, jean-frederic clere <jfcl...@gmail.com> wrote: > On 12/15/2015 03:16 PM, Jan Kaluža wrote: >> On 12/15/2015 02:16 PM, Yann Ylavic wrote: >>> Hi Jan, >>> >>> On Tue, Dec 15, 2015 at 12:51 PM, Jan Kaluža <jkal...@redhat.

Re: mod_mime_magic, gzipped tarballs and Docker

Hi, On Fri, Jan 8, 2016 at 8:49 AM, Jan Kaluža wrote: > > Content-Type: application/x-tar > Content-Encoding: x-gzip [] > > So, the mod_mime_magic is saying here that the body is tarball encoded by > gzip. AIUI, mod_mime_magic does indeed try to uncompress the tar.gz and

Re: svn commit: r1722369 - in /httpd/httpd/trunk: ./ docs/manual/mod/ modules/http2/

On Wed, Dec 30, 2015 at 5:12 PM, wrote: > Author: icing > Date: Wed Dec 30 16:12:35 2015 > New Revision: 1722369 > > URL: http://svn.apache.org/viewvc?rev=1722369=rev > Log: > fixes after fuzzing tests, changed H2KeepAliveTimeout default > [] > > Modified:

Re: svn commit: r1715876 - in /httpd/httpd/trunk: modules/cache/ modules/filters/ modules/generators/ modules/http/ modules/http2/ modules/loggers/ modules/mappers/ modules/metadata/ modules/proxy/ mo

On Mon, Nov 23, 2015 at 8:37 PM, Ruediger Pluem wrote: > > On 11/23/2015 05:46 PM, yla...@apache.org wrote: >> >> -case 'p': >> -case 'P': { >> -/* handle most common quickest cases... */ >> -if (!strcmp(token, "private"))

Re: svn commit: r1715876 - in /httpd/httpd/trunk: modules/cache/ modules/filters/ modules/generators/ modules/http/ modules/http2/ modules/loggers/ modules/mappers/ modules/metadata/ modules/proxy/ mo

On Mon, Nov 23, 2015 at 9:00 PM, Marion & Christophe JAILLET wrote: > Hi, > > 1 typo below. Fixed in r1715938, thanks. > > Moreover, this kind of patch is a good candidate for backport as it > introduces many small differences between 2.4 and trunk. > Without a

Re: strncasecmp

Hi Christophe, On Mon, Nov 23, 2015 at 9:12 PM, Christophe JAILLET wrote: > > I tried to do some but the benefit of the optimized version is not that > clear, at least on my system: >gcc 5.2.1 >Linux linux 4.2.0-18-generic #22-Ubuntu SMP Fri Nov 6 18:25:50

Re: Better ap_casecmpstr[n]?

gt; If we really want to squeek out optimizations, judicious use > of 'register' might help even... > > But after awhile things start getting silly :) > >> On Nov 24, 2015, at 1:04 PM, Yann Ylavic <ylavic@gmail.com> wrote: >> >> I did some testing with

Re: svn commit: r1715859 - /httpd/httpd/trunk/include/httpd.h

On Tue, Nov 24, 2015 at 7:24 PM, William A Rowe Jr wrote: > > Well, there is another option, reject API bloat and insist that > users set LC_ALL="C" if they want httpd to behave correctly > and performantly. Which API bloat? If we really want to avoid misleading anybody

Re: svn commit: r1715938 - /httpd/httpd/trunk/modules/cache/cache_util.c

On Tue, Nov 24, 2015 at 7:29 PM, William A Rowe Jr wrote: > > I'm wondering the other way around. Even in Yann's latest exercise, > simply testing > >if ((*ps1 == *ps2) || (ucharmap[*ps1] != ucharmap[*ps2])) { > > (or in Yann's code, use the const int lookups,

Re: Better ap_casecmpstr[n]?

On Tue, Nov 24, 2015 at 7:39 PM, Mikhail T. <mi+t...@aldan.algebra.com> wrote: > On 24.11.2015 13:04, Yann Ylavic wrote: > > int ap_casecmpstr_2(const char *s1, const char *s2) > { > size_t i; > const unsigned char *ps1 = (const unsigned char *) s1; > const

Re: svn commit: r1715938 - /httpd/httpd/trunk/modules/cache/cache_util.c

On Tue, Nov 24, 2015 at 5:18 PM, Graham Leggett <minf...@sharp.fm> wrote: > On 24 Nov 2015, at 6:15 PM, Yann Ylavic <ylavic@gmail.com> wrote: > >> Not sure: >>if (!strcmp(h, "max-age") >>|| ap_cmpcasestr(h, "max-age")) >

Re: svn commit: r1715938 - /httpd/httpd/trunk/modules/cache/cache_util.c

On Tue, Nov 24, 2015 at 5:09 PM, Graham Leggett wrote: > > A further optimisation - in many cases the fast path is really a case > sensitive string comparison, given that the vast majority of the time the > case being used is the case quoted in the spec. > > In other words,

Better ap_casecmpstr[n]?

I did some testing with different implémentations and my results show that fastest one is: int ap_casecmpstr_2(const char *s1, const char *s2) { size_t i; const unsigned char *ps1 = (const unsigned char *) s1; const unsigned char *ps2 = (const unsigned char *) s2; for (i = 0; ;

Re: svn commit: r1715938 - /httpd/httpd/trunk/modules/cache/cache_util.c

On Tue, Nov 24, 2015 at 7:03 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> On Nov 24, 2015, at 11:18 AM, Graham Leggett <minf...@sharp.fm> wrote: >> >> On 24 Nov 2015, at 6:15 PM, Yann Ylavic <ylavic@gmail.com> wrote: >>

Re: Better ap_casecmpstr[n]?

s2[i]]; > /* Above lookups are optimized away if first test below succeeds */ > > if ((ps1[i] != ps2[i]) && (c1 != c2)) { > return c1 - c2; > } > if (!c1) { > break; > } > } > retur

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

Sorry for the late, was afk this times... Regarding the name, I'm fine with ap[r]_cstr[n]casecmp(), ap[r]_casecmpcstr[n]() or ap[r]_cstr_*() (if we need a set of functions in this area).. I think we all agree that the new function(s) would help protocol "validation" being agnostic wrt the

Re: [openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http

Hi Bill, thanks, this will be quite useful. A little note, probably some missing == here: +else if (meth = TLSv1_2_client_method()) +BIO_printf(fbio, "Upgrade: TLS/1.2\r\n"); +else if (meth = TLSv1_1_client_method()) +BIO_printf(fbio, "Upgrade:

Re: svn commit: r1650655 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS modules/proxy/proxy_util.c

On Wed, Nov 18, 2015 at 1:58 PM, Michal Karm wrote: > > the patch suggested by Yenn [1][2] did not help the performance > results in any substantial capacity. The difference between having and not > having > > if (uri.port && uri.port ==

Re: svn commit: r1715363 - in /httpd/httpd/trunk/modules/http2: h2_request.c h2_response.h h2_session.c h2_stream.c h2_stream.h h2_util.c h2_util.h

On Fri, Nov 20, 2015 at 5:04 PM, Jim Jagielski wrote: > Ugg... I *just* noticed: > > However, header field names MUST be converted to lowercase > prior to their encoding in HTTP/2. A request or response > containing uppercase header field names MUST be

Re: svn commit: r1715375 - /httpd/httpd/trunk/CHANGES

On Fri, Nov 20, 2015 at 4:24 PM, wrote: > Author: icing > Date: Fri Nov 20 15:24:21 2015 > New Revision: 1715375 > > URL: http://svn.apache.org/viewvc?rev=1715375=rev > Log: > updated CHANGES > > Modified: > httpd/httpd/trunk/CHANGES > > Modified: httpd/httpd/trunk/CHANGES

Re: svn commit: r1715363 - in /httpd/httpd/trunk/modules/http2: h2_request.c h2_response.h h2_session.c h2_stream.c h2_stream.h h2_util.c h2_util.h

On Fri, Nov 20, 2015 at 2:58 PM, wrote: > Author: icing > Date: Fri Nov 20 13:58:32 2015 > New Revision: 1715363 > > URL: http://svn.apache.org/viewvc?rev=1715363=rev > Log: > incoming trailers passed into chunked request bodies, outgoing trailers not > supported yet > >

Re: svn commit: r1715375 - /httpd/httpd/trunk/CHANGES

tion of the file. > >> Am 20.11.2015 um 16:38 schrieb Yann Ylavic <ylavic@gmail.com>: >> >> On Fri, Nov 20, 2015 at 4:24 PM, <ic...@apache.org> wrote: >>> Author: icing >>> Date: Fri Nov 20 15:24:21 2015 >>> New Revision: 1715375 &

Re: svn commit: r1715363 - in /httpd/httpd/trunk/modules/http2: h2_request.c h2_response.h h2_session.c h2_stream.c h2_stream.h h2_util.c h2_util.h

" should never arrive. Same for "Transfer-Encoding: ". The current >>> implementation ignores. One could argue for deny. >>> For 2. certain headers we cannot send out and we need to take proper >>> actions for that. For example a "TE: deflate&q

Re: svn commit: r1715363 - in /httpd/httpd/trunk/modules/http2: h2_request.c h2_response.h h2_session.c h2_stream.c h2_stream.h h2_util.c h2_util.h

On Fri, Nov 20, 2015 at 4:44 PM, Stefan Eissing wrote: > Most of this is discussed here: > https://httpwg.github.io/specs/rfc7540.html#HttpHeaders > > Basically HTTP/2 defines its own connection properties, so several things > which are announced/controlled > by

Re: strncasecmp

+1 On Fri, Nov 20, 2015 at 6:17 PM, Jim Jagielski wrote: > We use str[n]casecmp quite a bit. The rub is that some > platforms use a sensible implementation (such as OSX) which > uses a upper-lowercase map and is v. fast, and others > use a brain-dead version which does an

Re: svn commit: r1715401 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h server/util.c

On Fri, Nov 20, 2015 at 7:49 PM, wrote: > Author: jim > Date: Fri Nov 20 18:49:38 2015 > New Revision: 1715401 > > URL: http://svn.apache.org/viewvc?rev=1715401=rev > Log: > Provide our own impl of str[n]casecmp() > > This simply provides it. Next step is to change all uses of >

Re: svn commit: r1715401 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h server/util.c

Alternatively, a single/simpler while (n--){} would work too. On Fri, Nov 20, 2015 at 11:17 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Fri, Nov 20, 2015 at 7:49 PM, <j...@apache.org> wrote: >> Author: jim >> Date: Fri Nov 20 18:49:38 2015 >> New

Re: Buffer size in mod_session_crypto.c, decrypt_string()

On Thu, Nov 19, 2015 at 10:14 AM, Dirk-Willem van Gulik wrote: > > Alternatively one could use > _decode_binary() in which case above terminator is absolutely needed. There > is no _binary_len(). Or use apr_pbase64_decode(pool, in) for clarity. (Even though it also

Re: svn commit: r1714742 - /httpd/httpd/branches/2.4.x/STATUS

On Wed, Nov 18, 2015 at 6:21 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > The problem was about "HTTP spoken on HTTPS port" handling in > ssl_io_filter_input() not prepared to AP_MODE_INIT from > process_connection() and AP_MODE_SPECULATIVE read for H2Di

Re: svn commit: r1715401 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h server/util.c

On Sat, Nov 21, 2015 at 2:54 PM, Jim Jagielski wrote: > I thought about that, but we don't have many do-whiles :) Fair enough :) > > But whatever people would prefer is fine w/ me... You convinced me.

Re: strncasecmp

cxcxcxcxcxcxcxcxcwwaa > xcxcxcxcxcxcxcxcxcxcwwaa 0 > (nb=1, len=0) > res = 0 > > real0m1.708s > user0m1.704s > sys0m0.000s > > > > > See atatchement. > > CJ > > > > Le 23/11/2015 21:33, Yann Ylav

Re: strncasecmp

Please note that the changes in ap_str[n]casecmp(), ie: ++ps1; ++ps2; was a first try/change which (obviously) did nothing. You may ignore it. On Mon, Nov 23, 2015 at 11:43 PM, Yann Ylavic <ylavic@gmail.com> wrote: > with attachment... > > On Mon, Nov 23, 2

Re: strncasecmp

with attachment... On Mon, Nov 23, 2015 at 11:42 PM, Yann Ylavic <ylavic@gmail.com> wrote: > I modified your test program a bit (to measure time from it, see > attached), tried with -O{2,3,s}, and except -Os I always have better > results with the "optimized" versio

Re: strncasecmp

On Tue, Nov 24, 2015 at 1:07 AM, Mikhail T. wrote: > > BTW, if the program measures its own time, should it not use getrusage() > instead of gettimeofday()? Well, it measures the time spent in the relevant code, with a monotonic clock, that should be fair enough. We

Re: strncasecmp

On Mon, Nov 23, 2015 at 11:42 PM, Yann Ylavic <ylavic@gmail.com> wrote: > except -Os I always have better > results with the "optimized" version To reach better performances with -Os, we could possibly use: int ap_strcasecmp(const char *s1, const char *s2) { co

Re: strncasecmp

FWIW, a new version using clock_gettime() instead of gettimeofday(). Same/Comparable results for optimized vs string.h's (the former wins but with -Os). On Tue, Nov 24, 2015 at 1:43 AM, Yann Ylavic <ylavic@gmail.com> wrote: > On Tue, Nov 24, 2015 at 1:24 AM, Mikhail

Re: strncasecmp

On Tue, Nov 24, 2015 at 12:46 AM, Mikhail T. <mi+t...@aldan.algebra.com> wrote: > On 23.11.2015 17:43, Yann Ylavic wrote: > > with attachment... > > There is a mistake somewhere in the optimized version: My bad, I somehow corrupted the original ap_str[n]casecmp() functions.

Re: strncasecmp

On Tue, Nov 24, 2015 at 1:24 AM, Mikhail T. wrote: > > Is there really a gain in inc- and decrementing this way? Would not it be > easier to read with the explicit increments -- and, incidentally, no > decrements at all? No measured difference in my tests, I guess it

Re: strncasecmp

On Tue, Nov 24, 2015 at 4:12 AM, Mikhail T. <mi+t...@aldan.algebra.com> wrote: > On 23.11.2015 19:43, Yann Ylavic wrote: > >> That's expected (or at least no cared about in this test case). We simply >> want res to not be optimized out, so print it before leaving, w

Re: svn commit: r1715789 - in /httpd/httpd/trunk: modules/cache/ modules/filters/ modules/generators/ modules/http/ modules/http2/ modules/loggers/ modules/mappers/ modules/metadata/ modules/proxy/ mo

On Mon, Nov 23, 2015 at 3:05 PM, Jim Jagielski wrote: > > That's cheating :) Yeah, reverted (r1715869) and re-committed (r1715876) with no functional change. Thanks for catching!

Re: strncasecmp

On Tue, Nov 24, 2015 at 6:10 AM, Mikhail T. wrote: > > Attached is the same program with one more pair of > functions added (and an easy way to add more "candidates" to the > main-driver). I changed the FOR-loop define to obtain repeatable results: This test program

Re: svn commit: r1715789 - in /httpd/httpd/trunk: modules/cache/ modules/filters/ modules/generators/ modules/http/ modules/http2/ modules/loggers/ modules/mappers/ modules/metadata/ modules/proxy/ mo

Jagielski <j...@jagunet.com> wrote: > To be clear, I was only semi-joking about the code > changes (eg: apr_atoi64()) which did not involve > ap_casecmpstr() at all :) :) > > >> On Nov 23, 2015, at 11:50 AM, Yann Ylavic <ylavic@gmail.com> wrote: >> >> O

Re: svn commit: r1715938 - /httpd/httpd/trunk/modules/cache/cache_util.c

On Tue, Nov 24, 2015 at 4:28 PM, Eric Covener wrote: > On Tue, Nov 24, 2015 at 10:21 AM, Jim Jagielski wrote: >> For these types of paths, where we use a switch/case against >> the 1st char of the token, the real reason why we used that >> impl was to avoid

Re: svn commit: r1715876 - in /httpd/httpd/trunk: modules/cache/ modules/filters/ modules/generators/ modules/http/ modules/http2/ modules/loggers/ modules/mappers/ modules/metadata/ modules/proxy/ mo

On Tue, Nov 24, 2015 at 5:28 AM, William A Rowe Jr wrote: > > I didn't have a chance to review the patch, but all of the instances that 1. > map to an RFC protocol string comparison and 2. occur in 2.4 code base > *should* be coalesced into one patch. I'm +1 for every such

Re: svn commit: r1715938 - /httpd/httpd/trunk/modules/cache/cache_util.c

On Tue, Nov 24, 2015 at 4:49 PM, William A Rowe Jr wrote: > > Does it make sense to expose the ap_tolower_ascii() function? +1, possibly an inline one or a macro... > We could call it ap_tolower_plaintext() I prefer ascii().

Re: svn commit: r1714742 - /httpd/httpd/branches/2.4.x/STATUS

On Thu, Nov 19, 2015 at 1:26 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > Am I right to assume "H2Direct off" is the defaut now (in 2.5-dev and > upcoming 2.4.18, trunk docs seem not updated, and [1] suggests this is > from r1708107)? Hmm, then r1709587

Re: svn commit: r1714742 - /httpd/httpd/branches/2.4.x/STATUS

On Thu, Nov 19, 2015 at 2:04 PM, Stefan Eissing wrote: >> >> Hmm, then r1709587 swithed it back to "H2Direct on for http:, off for >> https: requests", whereas the commit states "H2Direct off, on when h2c >> is in Protocols". >> What's the status exactly? > > The

Re: svn commit: r1748371 - /httpd/httpd/branches/2.4.x/STATUS

On Tue, Jun 14, 2016 at 11:42 AM, wrote: > Author: ylavic > Date: Tue Jun 14 09:42:15 2016 > New Revision: 1748371 > > URL: http://svn.apache.org/viewvc?rev=1748371=rev > Log: > Propose fix for 2.4.21 (before release). > > Modified: > httpd/httpd/branches/2.4.x/STATUS > []

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

On Wed, May 25, 2016 at 5:11 PM, William A Rowe Jr wrote: > *) I intend to help maintain/test 2.2.x releases over the next [18] mos *) I intend to backport/review 2.2.x security patches over the next [18] mos

<    5   6   7   8   9   10   11   12   13   14   >