Re: mod_ftp segaults on rheloids

On Fri, Nov 11, 2016 at 2:24 AM, Benjamin Lefoul wrote: > Is this list still active? > Maybe it was not the right place to ask about mod_ftp? > It is the place to ask, and was on my list to respond to your question... sorry I'm overwhelmed with other code this week.

Re: svn commit: r1768245 - /httpd/httpd/trunk/modules/cache/mod_socache_memcache.c

On Sun, Nov 6, 2016 at 1:45 PM, Jim Jagielski wrote: > Why? We trust the apr_memcache.c returns the correct > response... No need to check the version of APR or > APU since mod_socache_memcache.c works fine no > matter what version is used. I missed that this is a trunk/2.4

Re: svn commit: r1768245 - /httpd/httpd/trunk/modules/cache/mod_socache_memcache.c

On Sun, Nov 6, 2016 at 10:57 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > Wrap this up in an #if APU_MAJOR_VERSION > 1 || APU_MINOR_VERSION > 6 > > before backporting? (Yes - these symbols will still exist in unifed APR2 > and later.) > #if APU_MAJOR_VERSION &g

Re: svn commit: r1768245 - /httpd/httpd/trunk/modules/cache/mod_socache_memcache.c

Wrap this up in an #if APU_MAJOR_VERSION > 1 || APU_MINOR_VERSION > 6 before backporting? (Yes - these symbols will still exist in unifed APR2 and later.) Since we can't demand users update apr to pick up 2.4.next, and some will be using the OS-deployed APR. On Nov 5, 2016 11:47 AM,

Re: svn commit: r1768079 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/ modules/http/http_filters.c

On Sat, Nov 5, 2016 at 10:38 AM, Yann Ylavic <ylavic@gmail.com> wrote: > On Sat, Nov 5, 2016 at 3:15 AM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > >> > >> On Fri, Nov 4, 2016 at 5:17 PM, Yann Ylavic <ylavic@gmail.com> > wrote: &

Re: svn commit: r1768079 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/ modules/http/http_filters.c

On Fri, Nov 4, 2016 at 9:14 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Fri, Nov 4, 2016 at 5:17 PM, Yann Ylavic <ylavic@gmail.com> wrote: > >> On Fri, Nov 4, 2016 at 10:15 PM, William A Rowe Jr <wr...@rowe-clan.net> >>

Re: svn commit: r1768079 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/ modules/http/http_filters.c

On Fri, Nov 4, 2016 at 5:17 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Fri, Nov 4, 2016 at 10:15 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > I'm really not clear how ap_map_http_request_error() arrived without the > > patch patch below, an

Re: svn commit: r1768036 - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c

On Fri, Nov 4, 2016 at 12:46 PM, Jacob Champion <champio...@gmail.com> wrote: > [spec discussion] > > On 11/04/2016 09:40 AM, William A Rowe Jr wrote: > >> On Fri, Nov 4, 2016 at 9:47 AM, Eric Covener <cove...@gmail.com >> <mailto:cove...@gmail.com>&

Re: ap_get_status_line(int)

Yes, you can find bugzilla entries on this topic. On Fri, Nov 4, 2016 at 11:23 AM, Yann Ylavic <ylavic@gmail.com> wrote: > On Fri, Nov 4, 2016 at 2:09 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > > > What would a non-three-digit, >599 re

Re: svn commit: r1768036 - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c

On Fri, Nov 4, 2016 at 11:40 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > Give me about 24 hours to complete all this work, end of day today > is my most optimistic timetable. Then we can discuss the resulting > delta as a single unit/backport vote. Becaus

Re: svn commit: r1768036 - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c

On Fri, Nov 4, 2016 at 9:47 AM, Eric Covener wrote: > On Fri, Nov 4, 2016 at 10:20 AM, wrote: > > * that the Location response header (if present) has a valid scheme and > is > >absolute > > Too strict? > >

Re: ap_get_status_line(int)

On Thu, Nov 3, 2016 at 12:51 PM, Stefan Eissing < stefan.eiss...@greenbytes.de> wrote: > Like to get your opinion: > > ap_get_status_line(int) converts any status code it does not know into a > 500. This is fine for the use cases we had so far, although it can be > discussed if it is a good idea,

Re: failing t/php/safemode.t

On Thu, Nov 3, 2016 at 3:42 AM, Petr Gajdos wrote: > Hi, > > http://php.net/manual/en/features.safe-mode.php > > safe mode is removed from php 5.4 on. Maybe candidate to drop? > Seems any feature specific to PHP 5.5 or earlier should be eliminated. Any behavior changed between

Re: failing t/php/strings2.t

On Wed, Nov 2, 2016 at 1:27 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Tue, Nov 1, 2016 at 10:24 AM, Petr Gajdos <pgaj...@suse.cz> wrote: > >> On Tue, Nov 01, 2016 at 10:12:31AM -0500, William A Rowe Jr wrote: >> > On Tue, Nov 1, 2016 at 8:22 AM, Pe

Re: Redis and mod_cache/mod_socache

On Mon, Oct 31, 2016 at 10:49 AM, Graham Leggett wrote: > On 31 Oct 2016, at 5:05 PM, Jim Jagielski wrote: > > > Moving to APR: > > > > Query: Think it would be worth my time to work on a Redis > > implementation for APR-util? I am working on a minimal Redis

Re: failing t/php/strings2.t

On Tue, Nov 1, 2016 at 10:24 AM, Petr Gajdos <pgaj...@suse.cz> wrote: > On Tue, Nov 01, 2016 at 10:12:31AM -0500, William A Rowe Jr wrote: > > On Tue, Nov 1, 2016 at 8:22 AM, Petr Gajdos <pgaj...@suse.cz> wrote: > > $ php -r 'var_dump(rawurlenco

Re: failing t/php/strings2.t

On Tue, Nov 1, 2016 at 8:22 AM, Petr Gajdos wrote: > Hi, > > php 5.2 rawurlencode() converts tilde to %7E, this is not true from php > 5.3 on, though: > > $ php -r 'var_dump(rawurlencode("~"));' > string(1) "~" > $ > > http://php.net/manual/en/function.rawurlencode.php > >

Re: Release date for Apache 2.2.32

On Mon, Oct 24, 2016 at 10:15 AM, Brian King wrote: > Is there a planned target date for the release of apache 2.2.32? > > Security scanning products (E.g. Rapid7) are recommending upgrading apache > to 2.2.32 because of the July announcement regarding httpoxy: > >

Re: [PATCH] Introducing mod_brotli

enum boolval { false = 0; is not that challenging. On Oct 19, 2016 7:38 PM, "Jacob Champion" wrote: > On 09/16/2016 05:32 AM, Evgeny Kotkov wrote: > >> This patch adds a module for dynamic Brotli (RFC 7932) compression in >> httpd. >> > > Just in case someone else runs

Re: svn commit: r1764961 - in /httpd/httpd/trunk: docs/manual/mod/core.xml modules/http/http_filters.c server/core.c server/gen_test_char.c server/protocol.c server/util.c

On Sat, Oct 15, 2016 at 6:23 PM, Rainer Jung wrote: > Am 14.10.2016 um 22:48 schrieb wr...@apache.org: > >> Author: wrowe >> Date: Fri Oct 14 20:48:43 2016 >> New Revision: 1764961 >> >> URL: http://svn.apache.org/viewvc?rev=1764961=rev >> Log: >> >> Dropped the

Re: svn commit: r1765475 - /httpd/httpd/trunk/modules/http/http_filters.c

Personally, I find this case of 1*hexdig ";" to more closely resemble the new rule of field-name ":" OWS field-value, which introduces a MUST reject for whitespace following request field-name in 7230 3.2.4. But Roy accepts that the implied *LWS rule is appropriate based on the errata request,

Re: svn commit: r1764961 - in /httpd/httpd/trunk: docs/manual/mod/core.xml modules/http/http_filters.c server/core.c server/gen_test_char.c server/protocol.c server/util.c

On Mon, Oct 17, 2016 at 1:48 PM, Roy T. Fielding <field...@gbiv.com> wrote: > On Oct 15, 2016, at 2:10 AM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > On Sat, Oct 15, 2016 at 3:54 AM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > >> On Fri

Re: svn commit: r1764961 - in /httpd/httpd/trunk: docs/manual/mod/core.xml modules/http/http_filters.c server/core.c server/gen_test_char.c server/protocol.c server/util.c

I see you made nearly all the adjustments I missed, apologies that I neglected the includes/ update. On Oct 15, 2016 9:01 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: > Yes, sorry... I meant to commit these all at once. Patch incoming. > > On Oct 15, 2

Re: svn commit: r1764961 - in /httpd/httpd/trunk: docs/manual/mod/core.xml modules/http/http_filters.c server/core.c server/gen_test_char.c server/protocol.c server/util.c

Yes, sorry... I meant to commit these all at once. Patch incoming. On Oct 15, 2016 6:23 PM, "Rainer Jung" wrote: > Am 14.10.2016 um 22:48 schrieb wr...@apache.org: > >> Author: wrowe >> Date: Fri Oct 14 20:48:43 2016 >> New Revision: 1764961 >> >> URL:

Re: headers.t error on 2.4 HEAD

Thanks. Another option in these cases is to mark the test TODO and gracefully ignore it's failure, but this fix is fine in the interim. On Oct 15, 2016 10:35 AM, "Yann Ylavic" wrote: > On Sat, Oct 15, 2016 at 4:30 PM, Yann Ylavic wrote: > > On Sat,

Re: svn commit: r1764961 - in /httpd/httpd/trunk: docs/manual/mod/core.xml modules/http/http_filters.c server/core.c server/gen_test_char.c server/protocol.c server/util.c

On Sat, Oct 15, 2016 at 3:54 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Fri, Oct 14, 2016 at 4:44 PM, Roy T. Fielding <field...@gbiv.com> > wrote: > >> Right, though several people have requested it now as errata. Seems >> likely

Re: svn commit: r1764961 - in /httpd/httpd/trunk: docs/manual/mod/core.xml modules/http/http_filters.c server/core.c server/gen_test_char.c server/protocol.c server/util.c

On Fri, Oct 14, 2016 at 4:44 PM, Roy T. Fielding wrote: > Right, though several people have requested it now as errata. Seems likely > to be in the final update for STD. > In the HttpProtocolOptions Unsafe mode, it is tolerated. Should it be the proper 'Strict' behavior to

Re: svn commit: r1764961 - in /httpd/httpd/trunk: docs/manual/mod/core.xml modules/http/http_filters.c server/core.c server/gen_test_char.c server/protocol.c server/util.c

On Fri, Oct 14, 2016 at 3:48 PM, wrote: > Author: wrowe > Date: Fri Oct 14 20:48:43 2016 > New Revision: 1764961 > > URL: http://svn.apache.org/viewvc?rev=1764961=rev > Log: > [...] > Apply HttpProtocolOptions Strict to chunk header parsing, invalid > whitespace is invalid,

Re: svn commit: r1688399 - /httpd/httpd/trunk/modules/metadata/mod_remoteip.c

On Fri, Oct 14, 2016 at 11:16 AM, Eric Covener wrote: > This was not backported and popped up in PR60251. > > Bill, can you have a look including my guess that it really should > just be "temp_sa = r->useragent_addr;"? While that code should *not* be triggered before

Re: 2.4.24 soon?

On Mon, Sep 19, 2016 at 10:36 AM, Jim Jagielski <j...@jagunet.com> wrote: > > > On Aug 2, 2016, at 2:59 PM, Jacob Champion <champio...@gmail.com> wrote: > > > > On 08/02/2016 11:12 AM, William A Rowe Jr wrote: > >> One additional thought... On 2.2 and

Re: Usability testing for httpd

On Mon, Sep 26, 2016 at 2:57 PM, Jacob Champion wrote: > Hi all, > > I attended the GNOME project's LAS [1] in Portland this past week, and one > of things that stuck with me was a presentation on usability testing by Jim > Hall. The usability of our configuration language

Re: StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]

On Tue, Sep 13, 2016 at 5:07 PM, Jacob Champion wrote: > On 09/13/2016 12:25 PM, Jacob Champion wrote: > >> What is this? Is this the newest "there are a bunch of almost-right >> implementations so let's make yet another standard in the hopes that it >> won't make things

Re: StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]

On Tue, Sep 13, 2016 at 10:55 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Mon, Sep 12, 2016 at 9:19 PM, Eric Covener <cove...@gmail.com> wrote: > >> >> For others who might hit a maze of closed/duped bug reports this one >> is active this y

Re: StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]

On Mon, Sep 12, 2016 at 9:19 PM, Eric Covener <cove...@gmail.com> wrote: > On Mon, Sep 12, 2016 at 5:38 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > It really seems that if a major client is not handling "|" correctly, we > > need to

Re: StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]

On Sep 13, 2016 3:36 AM, "Yann Ylavic" <ylavic@gmail.com> wrote: > > On Tue, Sep 13, 2016 at 10:10 AM, Ruediger Pluem <rpl...@apache.org> wrote: > > > > > > On 09/13/2016 04:19 AM, Eric Covener wrote: > >> On Mon, Sep 12, 2016 at

Re: StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]

On Mon, Sep 12, 2016 at 3:06 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Mon, Sep 12, 2016 at 10:49 AM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > >> On Mon, Aug 29, 2016 at 1:04 PM, Ruediger Pluem <rpl...@apache.org> >> wrote: >> &

Re: StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]

On Mon, Sep 12, 2016 at 10:49 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Mon, Aug 29, 2016 at 1:04 PM, Ruediger Pluem <rpl...@apache.org> wrote: > >> >> On 08/29/2016 06:25 PM, William A Rowe Jr wrote: >> > Thanks all for the feedback

StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]

On Mon, Aug 29, 2016 at 1:04 PM, Ruediger Pluem <rpl...@apache.org> wrote: > > On 08/29/2016 06:25 PM, William A Rowe Jr wrote: > > Thanks all for the feedback. Status and follow-up questions inline > > > > On Thu, Aug 25, 2016 at 10:02 PM, William A Rowe Jr <

Re: Backporting HttpProtocolOptions survey

On Mon, Aug 29, 2016 at 1:04 PM, Ruediger Pluem <rpl...@apache.org> wrote: > > On 08/29/2016 06:25 PM, William A Rowe Jr wrote: > > Thanks all for the feedback. Status and follow-up questions inline > > > > On Thu, Aug 25, 2016 at 10:02 PM, William A Rowe Jr <

Re: httpd track in Seville

On Sep 12, 2016 7:28 AM, "jean-frederic clere" wrote: > > On 08/30/2016 03:34 PM, Rich Bowen wrote: > > As you know, the CFP for ApacheCon closes in less than 2 weeks. It would > > be awesome if we could pull together an httpd track, highlighting that > > httpd is still the

Re: httpd track in Seville

On Tue, Aug 30, 2016 at 8:34 AM, Rich Bowen wrote: > > To this end, we've started to put together a proposed list of talks that > we'd like to see people submit, in the hopes that we end up with 2 days > - a user track, and a developer track - of httpd content. > >

Re: http2 symbol moved to proxy...

On Wed, Sep 7, 2016 at 8:57 AM, Eric Covener <cove...@gmail.com> wrote: > On Wed, Sep 7, 2016 at 9:20 AM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > Which means we can't bounce symbols from one shared object module > > to another without a major

Re: http2 symbol moved to proxy...

On Wed, Sep 7, 2016 at 5:54 AM, NormW wrote: > G/E > >> Index: modules/http2/NWGNUmod_http2 >> === >> --- modules/http2/NWGNUmod_http2(revision 1759564) >> +++ modules/http2/NWGNUmod_http2(working

Re: svn commit: r1748322 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h modules/dav/main/mod_dav.c modules/dav/main/mod_dav.h modules/dav/main/props.c modules/dav/main/providers.c

On Sep 2, 2016 7:07 AM, "Joe Orton" wrote: > > On Mon, Jun 13, 2016 at 10:33:36PM -, minf...@apache.org wrote: > > Author: minfrin > > Date: Mon Jun 13 22:33:35 2016 > > New Revision: 1748322 > > > > URL: http://svn.apache.org/viewvc?rev=1748322=rev > > Log: > > Allow other

Re: svn commit: r1758672 - in /httpd/httpd/branches/2.2.x: ./ CHANGES include/httpd.h server/protocol.c

On Wed, Aug 31, 2016 at 2:52 PM, wrote: > Author: ylavic > Date: Wed Aug 31 19:52:28 2016 > New Revision: 1758672 > > URL: http://svn.apache.org/viewvc?rev=1758672=rev > Log: > Merge r1710095, r1727544 from trunk: > > core: Limit to ten the number of tolerated empty lines

Re: svn commit: r1757407 - /httpd/httpd/branches/2.2.x/STATUS

Thanks Yann, I'll work from my notes and a fresh checkout to revise ASAP. On Aug 31, 2016 3:00 PM, "Yann Ylavic" <ylavic@gmail.com> wrote: > On Wed, Aug 31, 2016 at 9:57 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Wed, Aug 31, 2016 at 9:47 PM, William

Re: svn commit: r1757407 - /httpd/httpd/branches/2.2.x/STATUS

On Aug 31, 2016 2:31 PM, "Yann Ylavic" <ylavic@gmail.com> wrote: > > On Wed, Aug 31, 2016 at 9:05 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > > > One more reviewer would be appreciated to get these in sync, in preparation > > for the s

Re: svn commit: r1757407 - /httpd/httpd/branches/2.2.x/STATUS

On Thu, Aug 25, 2016 at 9:58 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Thu, Aug 25, 2016 at 7:42 AM, Eric Covener <cove...@gmail.com> wrote: > >> > + Backport: >> > + https://raw.githubusercontent.com/wrowe/ >> patches/ma

Re: httpd and letsencrypt

On Mon, Aug 29, 2016 at 2:52 PM, Jim Jagielski wrote: > Also, and this is personal, I don't tend to "trust" entities > with non-public membership: > > https://github.com/orgs/letsencrypt/people > > FWIW, looking through letskencrypt git commits, it seems to consist of only

Re: httpd and letsencrypt

On Aug 29, 2016 14:50, "Jim Jagielski" wrote: > > Key, of course (no pun intended) is a client impl with a suitable > and acceptable license. > > There is https://kristaps.bsd.lv/letskencrypt/, but last I looked > it required, iirc, LibreSSL as well as it still being somewhat >

Re: Backporting HttpProtocolOptions survey

Thanks all for the feedback. Status and follow-up questions inline On Thu, Aug 25, 2016 at 10:02 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > A couple key questions now that the full refactoring of legacy vs. strict > is mostly complete (there remain potential issues with som

Re: httpd and letsencrypt

Hi Rich, some thoughts inline... On Aug 29, 2016 10:09, "Josh Aas" wrote: > > Thanks for the intro Rich. > > I think it's important that we make HTTPS as easy as possible with > Apache httpd. I don't have a particular architecture in mind, my not > being an Apache dev, but

Re: httpd and letsencrypt

I think this is great, in concept. My experience with letsencrypt (which was quite good, FWIW) is that the project delivered a contained and trusted environment to sync and deliver new keys and retrieve signed certificates. I'll be interested to see what simplification is presented, I don't think

Re: Backporting HttpProtocolOptions survey

On Aug 25, 2016 22:02, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: > 3. Do we need multiple layers of 'Strict'ness, or should there be a single toggle, or no toggle, no tolerant input at all in the next 2.2/2.4 releases? My thoughts on three toggles ran like this... U

Backporting HttpProtocolOptions survey

A couple key questions now that the full refactoring of legacy vs. strict is mostly complete (there remain potential issues with some of the 3-4 yr old changes on trunk which I'll raise in other posts.) But speaking only to the request line and request header parsing... 1. Does it make sense to

Re: svn commit: r1757407 - /httpd/httpd/branches/2.2.x/STATUS

On Thu, Aug 25, 2016 at 7:42 AM, Eric Covener wrote: > > + Backport: > > + https://raw.githubusercontent.com/wrowe/patches/master/ > backport-2.2.x-r1710095-1727544.patch > > + +1: wrowe > > + > > backport link is bad > Fixed, thanks!

Re: svn commit: r1757407 - /httpd/httpd/branches/2.2.x/STATUS

So these cumulative 4 patches, each of which focuses on a different aspect of the request handling behavior, represent all of the fixes to 2.4.x that never made it to 2.2.x. With these proposals adopted, I can propose a nearly identical backport of the revised request handling logic to both 2.4.x

Re: svn commit: r1756978 - /httpd/httpd/trunk/server/gen_test_char.c

On Sun, Aug 21, 2016 at 9:49 AM, Yann Ylavic wrote: > On Sat, Aug 20, 2016 at 2:53 AM, wrote: > > > > Modified: httpd/httpd/trunk/server/gen_test_char.c > > URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/gen_ >

Re: State of trunk --enable-modules=reallyall build

On Fri, Aug 19, 2016 at 8:17 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Fri, Aug 19, 2016 at 6:14 PM, Yann Ylavic <ylavic@gmail.com> wrote: > >> >> How couldn't it figure out that apr_pstrcat() never returns NULL? >> Clever compi

State of trunk --enable-modules=reallyall build

On Fri, Aug 19, 2016 at 6:14 PM, Yann Ylavic wrote: > > How couldn't it figure out that apr_pstrcat() never returns NULL? > Clever compilers should really read all the docs :) > :) > Anyway, "fixed" in r1756976, thanks! > Thank you! My survey of

Re: svn commit: r1756946 - /httpd/httpd/trunk/server/gen_test_char.c

Eric, do you agree for the immediate future that we can live with this solution? On Fri, Aug 19, 2016 at 12:24 PM, wrote: > Author: wrowe > Date: Fri Aug 19 17:24:27 2016 > New Revision: 1756946 > > URL: http://svn.apache.org/viewvc?rev=1756946=rev > Log: > After lengthy

Re: An abbreviated background to this build error?

On Tue, Aug 2, 2016 at 6:38 AM, NormW wrote: > G/E; > Building for NetWare after 3+ months elsewhere, an get the following build > error: > >> Creating Build Helper gen_test_char.exe >> ### mwld.exe Linker Error: >> # Undefined symbol: _isascii in >> # gen_test_char.obj >>

Re: svn commit: r1740928 - in /httpd/httpd/trunk: ./ include/ modules/http2/ modules/proxy/ modules/ssl/ server/

Additional issues since this patch in our maintainer mode... httpd-2.x/modules/ssl/ssl_engine_config.c: In function 'ssl_cmd_SSLVerifyClient': httpd-2.x/modules/ssl/ssl_engine_config.c:1083:27: warning: 'mode' may be used uninitialized in this function [-Wmaybe-uninitialized]

Re: svn commit: r1756849 - /httpd/httpd/trunk/server/gen_test_char.c

Funny thing, but no. All that util.c is used for is mapping alpha, A == a. So long as every non-alpha point is unique, no issues. On Aug 19, 2016 2:43 AM, "Ruediger Pluem" wrote: > > > On 08/18/2016 10:41 PM, wr...@apache.org wrote: > > Author: wrowe > > Date: Thu Aug 18

Re: svn commit: r1756649 - in /httpd/httpd/trunk: docs/manual/mod/core.xml server/core.c

+1 On Aug 18, 2016 2:25 PM, "Christophe JAILLET" wrote: > HttpProtocolOptions (in code) or HTTPProtocolOptions (in doc) > > This should be consistent, and I'm +1 for HttpProtocolOptions. > > CJ > > Le 17/08/2016 à 18:24, wr...@apache.org a écrit : > >> Author:

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On Thu, Aug 18, 2016 at 5:00 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > Just FWIW, this still is not fixed for the legacy header parser. > > It *is* now fixed for the HTTP Request Line parser. Relaxing the > whitespace rule (as we still do by default) only lets 1+ SP/H

--enable-maintainer-mode conflict

I'm wondering if we would agree that a new flag, such as --enable-httpd-maintainer-mode would let us disambiguate our flag from the automake built-in flag, at least for trunk? Thoughts or alternate suggestions?

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

trunk/server/protocol.c > > > > On 08/04/2016 01:11 PM, William A Rowe Jr wrote: > > > At our kindest, we would like to let people keep upgrading on the 2.2 > > > or 2.4 branches of httpd for other fixes, without breaking their > > > deployments. > > > &

Re: HTTP/1.1 strict ruleset

t; Subject: Re: HTTP/1.1 strict ruleset > > > > On Thu, Aug 11, 2016 at 6:56 PM, William A Rowe Jr <wr...@rowe-clan.net> > > wrote: > > > > > > I haven't dug terribly deeply into the proxy mechanics yet, but the > same > > > parser for headers is used

Re: svn commit: r1756540 - in /httpd/httpd/trunk: docs/manual/mod/core.xml modules/http/http_filters.c server/core.c server/protocol.c server/vhost.c

On Aug 16, 2016 4:39 PM, "Yann Ylavic" wrote: > > On Tue, Aug 16, 2016 at 8:11 PM, wrote: > > Author: wrowe > > Date: Tue Aug 16 18:11:14 2016 > > New Revision: 1756540 > > > > URL: http://svn.apache.org/viewvc?rev=1756540=rev > > Log: > > Rename the

Re: svn commit: r1756186 - in /httpd/httpd/trunk: include/ modules/http/ modules/proxy/

On Aug 14, 2016 3:35 PM, "Yann Ylavic" wrote: > > > Why the change in log level? > > Reading a response before any request was sent looks quite severe to > me, a warning might better alert the admin about some (backend) > misbehaviour/response splitting, while a debug could

Re: svn commit: r1756186 - in /httpd/httpd/trunk: include/ modules/http/ modules/proxy/

It is an abusive attempt, yes. But noise for every abuse is an issue for admins attempting to trim their log file details. Warning exists only to alert the admin of some action they should take. This abuse attempt failed, so no action needed IMO. On Aug 14, 2016 3:35 PM, "Yann Ylavic"

Re: HTTP/1.1 strict ruleset

On Thu, Aug 11, 2016 at 6:14 PM, Roy T. Fielding wrote: > I have no idea why there is any need to discuss EBCDIC here, since HTTP > itself > is never EBCDIC. We should not be transforming any input to EBCDIC until > after the request has been parsed. > Just as a point of

Re: HTTP/1.1 strict ruleset

On Aug 11, 2016 15:09, "Eric Covener" wrote: > > On Thu, Aug 11, 2016 at 4:04 PM, Jim Jagielski wrote: > >> It seems that the two need some potentially different > >> rulesets. If you are running a forward proxy, you would want to be quite > >> strict about

Re: svn commit: r1755882 - in /httpd/httpd/branches/2.4.x-openssl-1.1.0-compat: ./ modules/ssl/ssl_engine_kernel.c

On Aug 11, 2016 1:59 PM, "Rainer Jung" <rainer.j...@kippdata.de> wrote: > > Am 11.08.2016 um 19:53 schrieb William A Rowe Jr: > >> On Aug 10, 2016 4:58 PM, <rj...@apache.org <mailto:rj...@apache.org>> wrote: >>> >>> >>> Auth

Re: svn commit: r1755882 - in /httpd/httpd/branches/2.4.x-openssl-1.1.0-compat: ./ modules/ssl/ssl_engine_kernel.c

On Aug 10, 2016 4:58 PM, wrote: > > Author: rjung > Date: Wed Aug 10 21:58:47 2016 > New Revision: 1755882 > > URL: http://svn.apache.org/viewvc?rev=1755882=rev > Log: > Silence more "defined but not used" compiler > warnings when building against OpenSSL 0.9.8a. Just a quick

Re: HTTP/1.1 strict ruleset

On Thu, Aug 11, 2016 at 11:54 AM, Eric Covener <cove...@gmail.com> wrote: > On Thu, Aug 11, 2016 at 12:44 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > Just to be clear, that is now 2 votes for eliminating the 'classic > parser' > > from all >

Re: HTTP/1.1 strict ruleset

On Thu, Aug 11, 2016 at 11:49 AM, Eric Covener <cove...@gmail.com> wrote: > On Thu, Aug 11, 2016 at 12:44 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > Since I've heard little support in these past weeks for leaving an HTTP > > strict > > 'lo

Re: HTTP/1.1 strict ruleset

On Thu, Aug 11, 2016 at 7:20 AM, Jim Jagielski wrote: > > > On Aug 4, 2016, at 6:21 PM, Roy T. Fielding wrote: > > > > > > Leaving existing users in a broken state of non-compliance with the > primary > > Internet standard we are claiming to implement just

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

st". So for example "now() + 2 hours" in the >>> "America/Los_Angeles" timezone would still get interpreted as "in the past" >>> by httpd, avoiding any datetime correction to GMT now(). >>> >>> Same example with the code change that we have originally propose

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On Aug 5, 2016 3:43 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: > > Our strict mode parsing still permits simple "\n" line termination rather than the CRLF as defined by spec. Here again, I can't find a security or integrity issue. > > In neith

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Mon, Aug 8, 2016 at 11:24 AM, Eric Covener <cove...@gmail.com> wrote: > On Mon, Aug 8, 2016 at 12:03 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > Easier is to do a compile time comparison of '\n' to 0x15 vs 0x25. But I > > need to know the mystery

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Aug 5, 2016 4:37 PM, "Eric Covener" <cove...@gmail.com> wrote: > > On Fri, Aug 5, 2016 at 4:58 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Thu, Aug 4, 2016 at 2:33 PM, William A Rowe Jr <wr...@rowe-clan.net> > > wrote: > >>

Re: svn commit: r1715880 - in /httpd/httpd/trunk: modules/aaa/ modules/cache/ modules/dav/main/ modules/filters/ modules/generators/ modules/http/ modules/http2/ modules/loggers/ modules/mappers/ modu

On Sun, Aug 7, 2016 at 12:16 AM, Christophe JAILLET < christophe.jail...@wanadoo.fr> wrote: > > Anyway, while looking at it, I noticed the code below. > I think that it is a leftover because I don't see any reason to handle > these 2 string comparisons differently. > >> Agreed, this looks like a

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 2:33 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Thu, Aug 4, 2016 at 2:01 PM, Eric Covener <cove...@gmail.com> wrote: > >> On Mon, Aug 1, 2016 at 3:22 PM, William A Rowe Jr <wr...@rowe-clan.net> >> wrote: >> &g

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On Aug 4, 2016 3:02 PM, "Roy T. Fielding" <field...@gbiv.com> wrote: >> >> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > >> If not, then stripping trailing whitespace from the line prior to obs-fold and >> e

Re: svn commit: r1755124 - /httpd/httpd/trunk/server/protocol.c

On Fri, Aug 5, 2016 at 12:50 PM, Yann Ylavic wrote: > > while adding > > the unnecessary verification of last_len != 0 from line 904, so I'd say > it's > > a > > net loss of legibility in spite of gaining us 4 characters. Just my 2c. > > The 'len' verification is necessary

Re: svn commit: r1755124 - /httpd/httpd/trunk/server/protocol.c

On Fri, Aug 5, 2016 at 10:43 AM, Yann Ylavic wrote: > @@ -903,8 +903,16 @@ AP_DECLARE(void) ap_get_mime_headers_core(request_ > */ > continue; > } > -else if (last_field != NULL) { > > +if (last_field == NULL) { > +

Re: svn commit: r1755343 - /httpd/httpd/trunk/server/protocol.c

On Fri, Aug 5, 2016 at 10:08 AM, wrote: > Author: ylavic > Date: Fri Aug 5 15:08:24 2016 > New Revision: 1755343 > > URL: http://svn.apache.org/viewvc?rev=1755343=rev > Log: > Follow up to r1755264. > Don't crash when ap_rgetline() returns a NULL field on ENOSPC. > > +

Re: Core on trunk for t/apache/limits.t

On Fri, Aug 5, 2016 at 9:27 AM, Rainer Jung wrote: > Am 05.08.2016 um 16:06 schrieb Jim Jagielski: > >> Testing HEAD on trunk I see t/apache/limits.t failing w/ >> a core dump on OSX 10.11.6: >> >> t/apache/limits.t .. 4/12 # Failed test 4 in t/apache/limits.t at line >>

Proposed, 2 week termination of mod_authnz_ldap component

As previously identified and familiar to all who are working with httpd trunk, httpd has not compiled against apr trunk in about 6 years. It seems time to evict the component from httpd core, given that it is neither supportable or maintainable. The ABI contract offered by APR, of no external

Re: HTTP/1.1 strict ruleset

On Thu, Aug 4, 2016 at 8:05 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Thu, Aug 4, 2016 at 5:21 PM, Roy T. Fielding <field...@gbiv.com> wrote: > >> On Aug 4, 2016, at 3:02 PM, William A Rowe Jr <wr...@rowe-clan.net> >> wrote: >> >&

Re: HTTP/1.1 strict ruleset

On Thu, Aug 4, 2016 at 5:21 PM, Roy T. Fielding <field...@gbiv.com> wrote: > On Aug 4, 2016, at 3:02 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > If consensus here agrees that no out-of-spec behavior should be tolerated > anymore, I'll jump on board. I'm alread

Re: HTTP/1.1 strict ruleset

On Thu, Aug 4, 2016 at 3:46 PM, Roy T. Fielding <field...@gbiv.com> wrote: > > On Aug 3, 2016, at 4:33 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > > > So it seems pretty absurd we are coming back to this over > > three years later, but is th

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 4:29 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Thu, Aug 4, 2016 at 11:10 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > On Thu, Aug 4, 2016 at 3:52 PM, Yann Ylavic <ylavic@gmail.com> > wrote: > >> > >>

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 3:52 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Thu, Aug 4, 2016 at 9:33 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > > > It seems correcting the table is the correct way to go, by direct > > observation, and placing g

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

Thanks for the feedback... On Thu, Aug 4, 2016 at 3:02 PM, Roy T. Fielding <field...@gbiv.com> wrote: > On Aug 3, 2016, at 2:28 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > So AIUI, the leading SP / TAB whitespace in a field is a no-op (usually > repre

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 2:54 PM, Eric Covener <cove...@gmail.com> wrote: > On Thu, Aug 4, 2016 at 3:33 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > It seems correcting the table is the correct way to go, by direct > > observation > > #error if

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 2:01 PM, Eric Covener <cove...@gmail.com> wrote: > On Mon, Aug 1, 2016 at 3:22 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > We have a few choices, but the bottom line is that we treat /r/n > > as 0x0a 0x15 on ebcdic, and

Re: HTTP/1.1 strict ruleset

On Wed, Aug 3, 2016 at 6:51 PM, Eric Covener wrote: > > > 2. leave the default as 'not-strict'? Seems we should most > >strongly recommend that the server observe RFC's 2068, > >2616 and 723x, and not tolerate ancient behavior by default > >unless the admin insists

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