You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2016/11/04 14:47:12 UTC
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 server/util.c server/vhost.c
On Fri, Nov 4, 2016 at 10:20 AM, <wr...@apache.org> 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
--
Eric Covener
covener@gmail.com
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 server/util.c server/vhost.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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. 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.
>
(If you do spot something amiss, you can quickly check against /trunk/
to see if the defect has been addressed already, then it will likely be
caught in my exhaustive backport list.)
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 server/util.c server/vhost.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Nov 4, 2016 at 12:46 PM, Jacob Champion <ch...@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 <covener@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>>> There is even an example with no scheme:
>>>
>>> Location: /People.html#tim
>>>
>>
>> Not valid as a request (fragment not allowed)
>>
>
> ...but what does that have to do with the Location header? This is a valid
> and useful Location header value. (Clients won't send the fragment during
> the redirect; they'll save it to use during later presentation of the
> resource.)
Yup, this is an interesting point/question. Location header value !=
Request line URI value.
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 server/util.c server/vhost.c
Posted by Jacob Champion <ch...@gmail.com>.
[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 <covener@gmail.com
> <ma...@gmail.com>> wrote:
>> There is even an example with no scheme:
>>
>> Location: /People.html#tim
>
> Not valid as a request (fragment not allowed)
...but what does that have to do with the Location header? This is a
valid and useful Location header value. (Clients won't send the fragment
during the redirect; they'll save it to use during later presentation of
the resource.)
--Jacob
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 server/util.c server/vhost.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Nov 4, 2016 at 9:47 AM, Eric Covener <co...@gmail.com> wrote:
> On Fri, Nov 4, 2016 at 10:20 AM, <wr...@apache.org> 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.
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 server/util.c server/vhost.c
Posted by Nick Kew <ni...@apache.org>.
On Fri, 2016-11-04 at 10:47 -0400, Eric Covener wrote:
> Too strict?
Be conservative in what you send. An Absolute URL
is never going to be the wrong thing to send.
> https://tools.ietf.org/html/rfc7231#section-7.1.2
Another change from the HTTP RFCs we learned, where
Location MUST be absolute.
Though in practice, there was a lot of confusion,
with the CGI spec - and hence serverside apps -
permitting the relative semantics. Seems recent
HTTP came into line with CGI on this one.
--
Nick Kew