HTTP::Request->parse() handles leading double slashes in path incorrectly [rt.cpan.org #59570]

Migrated from rt.cpan.org#59570 (status was 'new')

Requestors:

• GUIDO@cpan.org

From guido@cpan.org on 2010-07-20 16:09:22:

use strict;
use URI;
use HTTP::Request;

my $request = HTTP::Request->parse('GET //foo/bar/baz?uvw#xyz HTTP/1.1');
warn $request->uri->authority;

my $uri = URI->new('//foo/bar/baz?uvw#xyz');
warn $uri->authority;
__END__

Output is "foo" both times. With libwww-perl 5.827 and URI 1.38.

The problem is caused by URI being too relaxed about the format of a
URI.  But I guess that cannot be fixed because it would break a lot of
existing code.

I think HTTP::Request->parse must be changed.  The Request-URI of the
Request-Line in HTTP/1.1 is either a *, an absolute URI, an absolute
path, or an authority.

Unfortunately my version of URI is too smart for being fixed here:

    my $uri = URI->new;
    $uri->path('//foo/bar/baz');
    warn $uri->authority;

This spits out a friendly warning that a leading double slash is
confusing, and it then happily forgets that this is just the path, not
an authority.  

In fact, a leading double slash in a path is not really confusing but it
is perfecly legal and all browsers send such requests, and they conform
to HTTP here.

I have no idea how this could be fixed in a clean way without giving up
the blessed-scalar-approach for URI.  But it basically renders the
HTTP::Request->parse() method useless.

Cheers,
Guido

Start with HTTP::Request->parse and reproduce the request-target case shown in the issue, comparing its result with the URI examples. Check the HTTP/1.1 request-target forms described in the report; done means a leading double slash in an absolute path is not treated as an authority while other forms continue to parse correctly.