Request should cope with empty path

[Andersmholmgren]

The following should be supported

new Request('GET', Uri.parse('http://localhost'));

Note also that the check on https://github.com/dart-lang/shelf/blob/master/lib/src/request.dart#L178 is a bit strange. It compares this.url etc but then prints the result of url, but this.url has gone through some processing so this is misleading.

Note: I started trying to do a PR for this but wasn't sure how best to implement it as no path leads naturally to url = '' and handlerPath = '' (or nulls if you prefer). Either way this is not currently allowed in shelf

[nex3]

Note also that the check on https://github.com/dart-lang/shelf/blob/master/lib/src/request.dart#L178 is a bit strange. It compares this.url etc but then prints the result of url, but this.url has gone through some processing so this is misleading.

This error should only be able to be hit when the user explicitly passes url.

Note: I started trying to do a PR for this but wasn't sure how best to implement it as no path leads naturally to url = '' and handlerPath = '' (or nulls if you prefer). Either way this is not currently allowed in shelf

It doesn't really make sense for server requests' URLs to not have a path component; no HTTP request can produce such a URL. That said, for convenience when constructing requests manually, I wouldn't mind translating a path-less URL to a URL with path / automatically.

[davenotik]

I believe the issue I'm struggling w/ is related.

print('Debug1: ' + request.handlerPath); // => /
print('Debug2: ' + request.url.path); // => (empty string)

request = request.change(path: "foo”); // Errors with e.g. RangeError: Value not in range: 5

If I access myapp.com, the url.path is actually an empty string. I think this is why I‘m getting the error when doing the request.change.

[nex3]

@davenotik That behavior is intended. You can't create a request whose url and handlerPath don't match its requestedUri. You could change requestedUri itself, but then the Request object loses all its information about the original HTTP request which breaks handlers' ability to tell where they exist in your server's URL space.

It's possible we should support this sort of request rewriting, and if you want to make a case for it feel free to open a new issue. But be aware that it's a lot more fraught than what change() does, which is just to move deeper in an existing URL.