Re: HTTP/1.1 strict ruleset

On Thu, Aug 18, 2016 at 4:26 AM, Plüm, Rüdiger, Vodafone Group < ruediger.pl...@vodafone.com> wrote: > > > -Original Message- > > From: Yann Ylavic [mailto:ylavic@gmail.com] > > Sent: Donnerstag, 11. August 2016 22:40 > > To: httpd-dev > &g

RE: HTTP/1.1 strict ruleset

> -Original Message- > From: Yann Ylavic [mailto:ylavic@gmail.com] > Sent: Donnerstag, 11. August 2016 22:40 > To: httpd-dev > 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:

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, at 9:59 AM, William A Rowe Jr wrote: > > 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 >

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 processing as well as the > request processing. They don't share the same code, though,

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: HTTP/1.1 strict ruleset

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 gateway of trusted backend >> servers and

Re: HTTP/1.1 strict ruleset

> On Aug 11, 2016, at 12:56 PM, William A Rowe Jr 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 gateway of trusted backend >

Re: HTTP/1.1 strict ruleset

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 branches, and

Re: HTTP/1.1 strict ruleset

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 that

Re: HTTP/1.1 strict ruleset

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 branches, and using only the strict parser, > unconditionally. > > That's actually 3 votes for

Re: HTTP/1.1 strict ruleset

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 that out, but replace it with > options to > independently toggle HTTPUnsafe and

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: HTTP/1.1 strict ruleset

> 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 far more frustrating. Bugs get fixed. Users

Re: HTTP/1.1 strict ruleset

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

Re: HTTP/1.1 strict ruleset

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 > anymore, I'll jump on board. I'm already in the consensus block

Re: HTTP/1.1 strict ruleset

> On Aug 4, 2016, at 3:02 PM, William A Rowe Jr wrote: > > On Thu, Aug 4, 2016 at 3:46 PM, Roy T. Fielding > wrote: > > On Aug 3, 2016, at 4:33 PM, William A Rowe Jr > >

Re: HTTP/1.1 strict ruleset

On Fri, Aug 5, 2016 at 12:02 AM, William A Rowe Jr wrote: > > It would be helpful if other PMC members would weigh in yea or nay on > dropping out-of-spec behaviors from 2.4 and 2.2 maintenance branches. IMHO we should keep an opt *out* strict mode for new errors 400 we

Re: HTTP/1.1 strict ruleset

On Thu, Aug 4, 2016 at 3:46 PM, Roy T. Fielding wrote: > > On Aug 3, 2016, at 4:33 PM, William A Rowe Jr > wrote: > > > > So it seems pretty absurd we are coming back to this over > > three years later, but is there any reason to preserve pre-RFC 2068 > >

Re: HTTP/1.1 strict ruleset

> On Aug 3, 2016, at 4:33 PM, William A Rowe Jr wrote: > > So it seems pretty absurd we are coming back to this over > three years later, but is there any reason to preserve pre-RFC 2068 > behaviors? I appreciate that Stefan was trying to avoid harming > existing deployment

Re: HTTP/1.1 strict ruleset

On Wed, Aug 03, 2016 at 06:58:26PM -0500, William A Rowe Jr wrote: > > I see a lot of value in logging when not applying the strict parsing, > > so you can passively assess your traffic for a day/week/month. > > That requires additional CPU, and significantly more code complexity. > In fact, I

Re: HTTP/1.1 strict ruleset

> Well, is there any point of detailing the specific offending field names? > The bad text received? To the consumer in the response error message, > or strictly to the logs? I don't think it's too important in the response. > We should log (once) the cause of a 400, but are the details

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

Re: HTTP/1.1 strict ruleset

On Wed, Aug 3, 2016 at 6:51 PM, Eric Covener wrote: > On Wed, Aug 3, 2016 at 7:33 PM, William A Rowe Jr > wrote: > > So it seems pretty absurd we are coming back to this over > > three years later, but is there any reason to preserve pre-RFC 2068 > >

Re: HTTP/1.1 strict ruleset

On Wed, Aug 3, 2016 at 7:33 PM, William A Rowe Jr wrote: > So it seems pretty absurd we are coming back to this over > three years later, but is there any reason to preserve pre-RFC 2068 > behaviors? I appreciate that Stefan was trying to avoid harming > existing deployment

HTTP/1.1 strict ruleset

So it seems pretty absurd we are coming back to this over three years later, but is there any reason to preserve pre-RFC 2068 behaviors? I appreciate that Stefan was trying to avoid harming existing deployment scenarios, but even as I'm about to propose that we backport all of this to 2.4 and 2.2,