On Wed, Nov 16, 2016 at 1:52 PM, Ruediger Pluem wrote:
>
> On 11/16/2016 01:05 PM, wr...@apache.org wrote:
> > Author: wrowe
> > Date: Wed Nov 16 12:05:53 2016
> > New Revision: 1769965
> >
> > URL: http://svn.apache.org/viewvc?rev=1769965&view=rev
> > Log:
> > Actually cause the Host header to b
On Wed, Nov 16, 2016 at 1:32 PM, Ruediger Pluem wrote:
>
> On 11/16/2016 01:08 PM, William A Rowe Jr wrote:
> >
> > Here's why I think the whole logic is busted and the preserve
> r->hostname is
> > the right thing to do for the outer request (not a child/clien
Can we agree on a keyword/wording convention here for httpd-2.5-dev?
--with-apr=PATH prefix for installed APR or the full path to
--with-pcre=PATHUse external PCRE library
--with-valgrind[=DIR] Enable code to reduce valgrind false positives
(option
On Tue, Nov 8, 2016 at 1:39 PM, Ruediger Pluem wrote:
>
> On 11/04/2016 03:20 PM, wr...@apache.org wrote:
> > Author: wrowe
> > Date: Fri Nov 4 14:20:16 2016
> > New Revision: 1768036
> >
> > URL: http://svn.apache.org/viewvc?rev=1768036&view=rev
> > Log:
> > Add an option to enforce stricter HT
More importantly, the commit message for those lines modified should credit
the original submitter(s)... Who may or may not even be committers to this
project.
On Nov 15, 2016 17:21, "Eric Covener" wrote:
> On Tue, Nov 15, 2016 at 11:18 AM, Mehvish.Rashid
> wrote:
> > Am assuming that commit on
On Mon, Nov 14, 2016 at 1:02 PM, wrote:
> Author: wrowe
> Date: Mon Nov 14 19:02:29 2016
> New Revision: 1769677
>
> URL: http://svn.apache.org/viewvc?rev=1769677&view=rev
> Log:
> Promote one patch, propose one historically tangled patch
>
> + *) Propose default strict RFC7230 behavior, and Htt
On Fri, Nov 11, 2016 at 9:01 AM, Paul Spangler wrote:
> On 10/17/2016 2:04 PM, Paul Spangler wrote:
>
>> Hello,
>>
>> Due to the way OpenSSL stores errors in a per-thread queue, functions
>> such as SSL_read followed by SSL_get_error may not produce the desired
>> result if the error queue is not
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.
The last 'release' is quite
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 httpd enhancement, n
On Sun, Nov 6, 2016 at 10:57 AM, William A Rowe Jr
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 > 1 || APU_MINOR_VERSION &
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, wrote:
>
On Sat, Nov 5, 2016 at 10:38 AM, Yann Ylavic wrote:
> On Sat, Nov 5, 2016 at 3:15 AM, William A Rowe Jr
> wrote:
> >>
> >> On Fri, Nov 4, 2016 at 5:17 PM, Yann Ylavic
> wrote:
> >>>
> >>> What differed is that http_filters' bail_out_on_er
On Fri, Nov 4, 2016 at 9:14 PM, William A Rowe Jr
wrote:
> On Fri, Nov 4, 2016 at 5:17 PM, Yann Ylavic wrote:
>
>> On Fri, Nov 4, 2016 at 10:15 PM, William A Rowe Jr
>> wrote:
>> > I'm really not clear how ap_map_http_request_error() arrived without the
>
On Fri, Nov 4, 2016 at 5:17 PM, Yann Ylavic wrote:
> On Fri, Nov 4, 2016 at 10:15 PM, William A Rowe Jr
> wrote:
> > I'm really not clear how ap_map_http_request_error() arrived without the
> > patch patch below, and unclear whether it does what the backport proposal
>
On Fri, Nov 4, 2016 at 12:46 PM, Jacob Champion
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 > <mailto:cove...@gmail.com>> wrote:
>>
>>> There is even an exa
Yes, you can find bugzilla entries on this topic.
On Fri, Nov 4, 2016 at 11:23 AM, Yann Ylavic wrote:
> On Fri, Nov 4, 2016 at 2:09 PM, William A Rowe Jr
> wrote:
> >
> > What would a non-three-digit, >599 response look like? Perhaps we have
> > a good case for a
On Fri, Nov 4, 2016 at 11:40 AM, William A Rowe Jr
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. Because of a huge number of
> intervening
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?
>
> https://tools.ietf.org/html/rfc7231#section-7.1.2
>
>The "Location" header fiel
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,
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 PHP 5.3 and later
On Wed, Nov 2, 2016 at 1:27 AM, William A Rowe Jr
wrote:
> On Tue, Nov 1, 2016 at 10:24 AM, Petr Gajdos 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 wrote:
>> > $
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
> > lib, related to work, which is ba
On Tue, Nov 1, 2016 at 10:24 AM, Petr Gajdos 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 wrote:
> > $ php -r 'var_dump(rawurlencode("~"));'
> > string(1) "~&q
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
>
> Following patch is perh
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:
>
> http://marc.info/?l=apache-http
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 into this: I gave mod_
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&view=rev
>> Log:
>>
>> Dropped the never-released ap_has_cntrls(
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, and
On Mon, Oct 17, 2016 at 1:48 PM, Roy T. Fielding wrote:
> On Oct 15, 2016, at 2:10 AM, William A Rowe Jr
> wrote:
>
> On Sat, Oct 15, 2016 at 3:54 AM, William A Rowe Jr
> wrote:
>
>> On Fri, Oct 14, 2016 at 4:44 PM, Roy T. Fielding
>> wrote:
>>
>>>
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" wrote:
> Yes, sorry... I meant to commit these all at once. Patch incoming.
>
> On Oct 15, 2016 6:23 PM, "Rainer Jung"
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: http://svn.apache.org/viewvc?rev=1764961&v
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, Oct 15, 2016 at 4:20 PM, Yann Ylavic
> wrote:
On Sat, Oct 15, 2016 at 3:54 AM, William A Rowe Jr
wrote:
> 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 HttpP
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 parse (never generate
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&view=rev
> Log:
> [...]
> Apply HttpProtocolOptions Strict to chunk header parsing, invalid
> whitespace is invalid, line termination
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 r->useragent_addr
has been
On Mon, Sep 19, 2016 at 10:36 AM, Jim Jagielski wrote:
>
> > On Aug 2, 2016, at 2:59 PM, Jacob Champion wrote:
> >
> > 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-i
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 (and the web server in
On Sep 14, 2016 12:59 PM, "Ruediger Pluem" wrote:
>
> On 09/14/2016 07:17 PM, Jacob Champion wrote:
> >
> > I think that's bad from a documentation and usability standpoint. If
WHATWG (hypothetically) decided to bless more
> > exceptions to the RFC, would we follow suit with StrictURI? Is
StrictUR
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 worse"? Does anyone know
On Tue, Sep 13, 2016 at 10:55 AM, William A Rowe Jr
wrote:
> On Mon, Sep 12, 2016 at 9:19 PM, Eric Covener wrote:
>
>>
>> For others who might hit a maze of closed/duped bug reports this one
>> is active this year:
>> https://bugzilla.mozilla.org/show_bug.cgi?id
On Mon, Sep 12, 2016 at 9:19 PM, Eric Covener wrote:
> On Mon, Sep 12, 2016 at 5:38 PM, William A Rowe Jr
> wrote:
> > It really seems that if a major client is not handling "|" correctly, we
> > need to carve out an exception,
>
> +1 to allow it.
>
> F
On Sep 13, 2016 3:36 AM, "Yann Ylavic" wrote:
>
> On Tue, Sep 13, 2016 at 10:10 AM, Ruediger Pluem
wrote:
> >
> >
> > On 09/13/2016 04:19 AM, Eric Covener wrote:
> >> On Mon, Sep 12, 2016 at 5:38 PM, William A Rowe Jr
wrote:
> >>>
On Mon, Sep 12, 2016 at 3:06 PM, William A Rowe Jr
wrote:
> On Mon, Sep 12, 2016 at 10:49 AM, William A Rowe Jr
> wrote:
>
>> On Mon, Aug 29, 2016 at 1:04 PM, Ruediger Pluem
>> wrote:
>>
>>>
>>> On 08/29/2016 06:25 PM, William A Rowe Jr wrote:
On Mon, Sep 12, 2016 at 10:49 AM, William A Rowe Jr
wrote:
> On Mon, Aug 29, 2016 at 1:04 PM, Ruediger Pluem 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 Mon, Aug 29, 2016 at 1:04 PM, Ruediger Pluem 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 <mailto:wr...@rowe-clan
On Mon, Aug 29, 2016 at 1:04 PM, Ruediger Pluem 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 <mailto:wr...@rowe-clan
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 flagship of the ASF, an
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.
>
> https://public.etherpad-mozilla
On Wed, Sep 7, 2016 at 8:57 AM, Eric Covener wrote:
> On Wed, Sep 7, 2016 at 9:20 AM, William A Rowe Jr
> wrote:
> > Which means we can't bounce symbols from one shared object module
> > to another without a major version bump :-(
>
> Maybe OK in this particular ca
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 copy)
>> @@ -369,7 +
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&view=rev
> > Log:
> > Allow other modules to bec
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&view=rev
> Log:
> Merge r1710095, r1727544 from trunk:
>
> core: Limit to ten the number of tolerated empty lines between request,
>
Thanks Yann, I'll work from my notes and a fresh checkout to revise ASAP.
On Aug 31, 2016 3:00 PM, "Yann Ylavic" wrote:
> On Wed, Aug 31, 2016 at 9:57 PM, Yann Ylavic wrote:
> > On Wed, Aug 31, 2016 at 9:47 PM, William A Rowe Jr
> wrote:
> >> On Aug 31
On Aug 31, 2016 2:31 PM, "Yann Ylavic" wrote:
>
> On Wed, Aug 31, 2016 at 9:05 PM, William A Rowe Jr
wrote:
> >
> > One more reviewer would be appreciated to get these in sync, in
preparation
> > for the stronger parser on both of the release branches.
>
&g
On Thu, Aug 25, 2016 at 9:58 AM, William A Rowe Jr
wrote:
> 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
>> > +
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 https://github.com/
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
> instable. I am hopi
Thanks all for the feedback. Status and follow-up questions inline
On Thu, Aug 25, 2016 at 10:02 PM, William A Rowe Jr
wrote:
> 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 c
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 I do have a user experi
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
On Aug 25, 2016 22:02, "William A Rowe Jr" 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...
Unsafe allows things
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 em
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!
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 a
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_
> test_char.c?rev=1756978&r1=1756977&r2=1756978&view=diff
> >
On Fri, Aug 19, 2016 at 8:17 PM, William A Rowe Jr
wrote:
> 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 :)
>>
>
> :)
&
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 --enable-modules=reallyall at the moment...
af
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&view=rev
> Log:
> After lengthy investigation wit
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
>> ### mwcc Driver
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]
dc->nVerifyC
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 20:41:27 2016
> > New R
+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: wrowe
>> Date: Wed Aug 17 16:24:23
On Thu, Aug 18, 2016 at 5:00 AM, William A Rowe Jr
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/HTAB
> slip through, and
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?
4548 - /httpd/httpd/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
> > > deploymen
t; Subject: Re: HTTP/1.1 strict ruleset
> >
> > On Thu, Aug 11, 2016 at 6:56 PM, William A Rowe Jr
> > wrote:
> > >
> > > I haven't dug terribly deeply into the proxy mechanics yet, but the
> same
> > > parser for headers is used for response header
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&view=rev
> > Log:
> > Rename the previously undocumented HTTPProtocol dir
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 stay unnoticed.
If thi
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" wrote:
On
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 information, that isn't
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 the responses. If you are only a gatew
On Aug 11, 2016 1:59 PM, "Rainer Jung" wrote:
>
> Am 11.08.2016 um 19:53 schrieb William A Rowe Jr:
>
>> On Aug 10, 2016 4:58 PM, mailto:rj...@apache.org>>
wrote:
>>>
>>>
>>> Author: rjung
>>> Date: Wed Aug 10 21:58:47 2016
>
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&view=rev
> Log:
> Silence more "defined but not used" compiler
> warnings when building against OpenSSL 0.9.8a.
Just a quick observation...
On Thu, Aug 11, 2016 at 11:54 AM, Eric Covener wrote:
> On Thu, Aug 11, 2016 at 12:44 PM, William A Rowe Jr
> wrote:
> > Just to be clear, that is now 2 votes for eliminating the 'classic
> parser'
> > from all
> > of trunk, 2.4.x and 2.2.x branc
On Thu, Aug 11, 2016 at 11:49 AM, Eric Covener wrote:
> On Thu, Aug 11, 2016 at 12:44 PM, William A Rowe Jr
> wrote:
> > Since I've heard little support in these past weeks for leaving an HTTP
> > strict
> > 'logging-only' option, I'm going to rip
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 because of
> unsubstantiated
> > FUD is
ld 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 proposed:
>>>
>>> ===
>>> HTTP/1.1 200 OK
>>&
On Aug 5, 2016 3:43 PM, "William A Rowe Jr" 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 neither case do we send bad data a
On Mon, Aug 8, 2016 at 11:24 AM, Eric Covener wrote:
> On Mon, Aug 8, 2016 at 12:03 PM, William A Rowe Jr
> wrote:
> > Easier is to do a compile time comparison of '\n' to 0x15 vs 0x25. But I
> > need to know the mystery of 0x25's value through iconv on your
&g
On Aug 5, 2016 4:37 PM, "Eric Covener" wrote:
>
> On Fri, Aug 5, 2016 at 4:58 PM, William A Rowe Jr
wrote:
> > On Thu, Aug 4, 2016 at 2:33 PM, William A Rowe Jr
> > wrote:
> >>
> >> On Thu, Aug 4, 2016 at 2:01 PM, Eric Covener wrote:
> >>
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 s
On Thu, Aug 4, 2016 at 2:33 PM, William A Rowe Jr
wrote:
> On Thu, Aug 4, 2016 at 2:01 PM, Eric Covener wrote:
>
>> On Mon, Aug 1, 2016 at 3:22 PM, William A Rowe Jr
>> wrote:
>> > We have a few choices, but the bottom line is that we treat /r/n
>> > as 0x0a
On Aug 4, 2016 3:02 PM, "Roy T. Fielding" wrote:
>>
>> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr
wrote:
>
>> If not, then stripping trailing whitespace from the line prior to
obs-fold and
>> eating all leading whitespace on the obs-fold line will resu
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 because it can be zero
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) {
> +/* Keep track of t
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&view=rev
> Log:
> Follow up to r1755264.
> Don't crash when ap_rgetline() returns a NULL field on ENOSPC.
>
> +
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
>> 168 fail #2
>> t/apache/l
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 head
On Thu, Aug 4, 2016 at 8:05 PM, William A Rowe Jr
wrote:
> On Thu, Aug 4, 2016 at 5:21 PM, Roy T. Fielding wrote:
>
>> On Aug 4, 2016, at 3:02 PM, William A Rowe Jr
>> wrote:
>>
>> If consensus here agrees that no out-of-spec behavior should be tolerated
>&
801 - 900 of 6469 matches
Mail list logo
