On Apr 11, 2006, at 2:55 PM, Nick Kew wrote:
On Tuesday 11 April 2006 22:10, William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
On 04/11/2006 04:00 AM, Roy T. Fielding wrote:
It probably needs to be updated for RFC 3986 anyway. The path
should
be set to "", not NULL. The HTTP server should
On Tuesday 11 April 2006 22:10, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
> > On 04/11/2006 04:00 AM, Roy T. Fielding wrote:
> >>It probably needs to be updated for RFC 3986 anyway. The path should
> >>be set to "", not NULL. The HTTP server should take care of the
> >>redirect from ""
Ruediger Pluem wrote:
On 04/11/2006 04:00 AM, Roy T. Fielding wrote:
It probably needs to be updated for RFC 3986 anyway. The path should
be set to "", not NULL. The HTTP server should take care of the
redirect from "" to "/", which in this case means the http-proxy
needs to check for "" whe
On 04/11/2006 04:00 AM, Roy T. Fielding wrote:
>
>
> It probably needs to be updated for RFC 3986 anyway. The path should
> be set to "", not NULL. The HTTP server should take care of the
> redirect from "" to "/", which in this case means the http-proxy
> needs to check for "" when it sends
Roy T. Fielding wrote:
On Apr 10, 2006, at 2:50 PM, Ruediger Pluem wrote:
I also thought initially to fix this in apr-util, but right know I am
not
sure about it, because IMHO apr_uri_parse should do generic uri parsing.
Setting an empty uri to "/" seems to be HTTP specific, so I am not sur
Nick Kew wrote:
Yes, it's legal. The leading slash is implied. Note: that's leading
slash, which is firmly different to a trailing slash in a path.
for abspath you are correct. but in general;
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//"
Davi Arnaut wrote:
It is legal. And Nick is right, that should be fixed in apr_uri. I will
send a patch tomorrow.
Once again, you describe the http: scheme. Let's be careful about our
assumptions, and ensure we don't further constrain apr_uri to the http
behavior :) I'm all for apr_uri 'doin
On Apr 10, 2006, at 2:50 PM, Ruediger Pluem wrote:
I also thought initially to fix this in apr-util, but right know I
am not
sure about it, because IMHO apr_uri_parse should do generic uri
parsing.
Setting an empty uri to "/" seems to be HTTP specific, so I am not
sure
if we should do this
On Mon, 10 Apr 2006 23:50:05 +0200
Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>
>
> On 04/10/2006 11:19 PM, Davi Arnaut wrote:
> > On Mon, 10 Apr 2006 16:01:29 -0500
> > "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Nick Kew wrote:
> >>
> >>>On Monday 10 April 2006 20:59, [EMAIL
On 04/11/2006 12:09 AM, Ruediger Pluem wrote:
>
> On 04/10/2006 10:21 PM, William A. Rowe, Jr. wrote:
>
>>-1 Veto.
>
>
> Rolled back by r393088.
Of course it must be r393087 :-).
Regards
Rüdiger
On 04/10/2006 10:21 PM, William A. Rowe, Jr. wrote:
> -1 Veto.
Rolled back by r393088.
Regards
Rüdiger
On Monday 10 April 2006 22:01, William A. Rowe, Jr. wrote:
> Nick Kew wrote:
> > On Monday 10 April 2006 20:59, [EMAIL PROTECTED] wrote:
> >>* Prevent r->parsed_uri.path from being NULL as this can cause
> >> segmentation faults e.g. in mod_cache. Set it to "/" in this case.
> >
> > A better fix to
On 04/10/2006 11:19 PM, Davi Arnaut wrote:
> On Mon, 10 Apr 2006 16:01:29 -0500
> "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
>
>
>>Nick Kew wrote:
>>
>>>On Monday 10 April 2006 20:59, [EMAIL PROTECTED] wrote:
>>>
>>>
>>>
* Prevent r->parsed_uri.path from being NULL as this can cause
On 04/10/2006 11:39 PM, Ruediger Pluem wrote:
>
>
>
> No arguing about your veto. I just try to understand it better to address it.
>
> So some questions:
>
> 1. As I just learned from RFC3986 an empty path is allowed (I was not aware
> of this
>before). But why do we set r->uri to "/"
On 04/10/2006 10:21 PM, William A. Rowe, Jr. wrote:
> -1 Veto.
>
> You aren't checking the scheme (other than that we've dumped CONNECT
> earlier
> in the code) so you don't know that this transform is appropriate. If you
> would like to test that scheme applies, you still have the question of
On Mon, 10 Apr 2006 16:01:29 -0500
"William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
> Nick Kew wrote:
> > On Monday 10 April 2006 20:59, [EMAIL PROTECTED] wrote:
> >
> >
> >>* Prevent r->parsed_uri.path from being NULL as this can cause segmentation
> >> faults e.g. in mod_cache. Set it to "/"
Nick Kew wrote:
On Monday 10 April 2006 20:59, [EMAIL PROTECTED] wrote:
* Prevent r->parsed_uri.path from being NULL as this can cause segmentation
faults e.g. in mod_cache. Set it to "/" in this case.
A better fix to that would surely be for apr_uri to guarantee
setting path to non-null o
On Monday 10 April 2006 20:59, [EMAIL PROTECTED] wrote:
> * Prevent r->parsed_uri.path from being NULL as this can cause segmentation
> faults e.g. in mod_cache. Set it to "/" in this case.
A better fix to that would surely be for apr_uri to guarantee
setting path to non-null on parsing a URI.
-1 Veto.
You aren't checking the scheme (other than that we've dumped CONNECT earlier
in the code) so you don't know that this transform is appropriate. If you
would like to test that scheme applies, you still have the question of unusual
methods (eg non-GET/non-POST)
[EMAIL PROTECTED] wrote:
19 matches
Mail list logo
