On Fri, Nov 4, 2016 at 9:47 AM, Eric Covener <[email protected]> wrote:
> On Fri, Nov 4, 2016 at 10:20 AM, <[email protected]> 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 field is used in some responses to refer to a > specific resource in relation to the response. The type of > relationship is defined by the combination of request method and > status code semantics. > > Location = URI-reference > > The field value consists of a single URI-reference. When it has the > form of a relative reference ([RFC3986], Section 4.2), the final > value is computed by resolving it against the effective request URI > ([RFC3986], Section 5). > > There is even an example with no scheme: > > Location: /People.html#tim > Not valid as a request (fragment not allowed) Beyond this, you may want to pend questions since there is a *very* long list of backports to get this fork in sync with httpd-2.x trunk. Much of the initial code has been re-thought and will take me the better part of the day to sequentially merge. For small groups of simple patches without much issue, I'm collapsing them (with credits and multiple rev no's) - especially where the 'next patch' undoes some of the changes in the prior patch and momentary flaw can be ignored. I still have some lingering questions, but this will get you the full picture of where the change came from when reviewing the overall delta between 2.4.now and 2.4.next. 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 commits to the relevant source files, mixing modern code changes based on nearly-4-year-old work in trunk is something of a nightmare (as we observed just syncing 2.2 to the state of the fixes already in 2.4.) I'll be starting a 2.2.current -> 2.4.current branch next, so the combination of that plus this trunk branch should get us to a parsing/strict observation shortly.
