Redirect loop when PATH_INFO is ""

[hrkfdn]

Cross-Referencing this, as I'm unsure if this needs to be fixed in Werkzeug or httpd:

reyk/httpd#71

TL;DR: OpenBSD httpd sets PATH_INFO to "" when the root URL (GET /) of an application mounted at root is requested. Flask/Werkzeug responds with a 301 redirect to "/". After the redirect, PATH_INFO is still "". This results in a redirect loop.

Which part is the culprit here? Werkzeug's automatic redirect or OpenBSD's PATH_INFO set to ""?

[davidism]

As a workaround, you can disable strict_slashes for the / route.

If you want to help out with this, figuring out what the relevant specs are and what they say about PATH_INFO would be a good start.

[hrkfdn]

I did look at the specs but I am unsure what to make of them, which is why I opened this issue. Otherwise I'd gladly have submitted a pull request ;)

Here is what the CGI RFC has to say about PATH_INFO:

The PATH_INFO variable specifies a path to be interpreted by the CGI
script. It identifies the resource or sub-resource to be returned by
the CGI script, and is derived from the portion of the URI path
hierarchy following the part that identifies the script itself.
Unlike a URI path, the PATH_INFO is not URL-encoded, and cannot
contain path-segment parameters. A PATH_INFO of "/" represents a
single void path segment.

  PATH_INFO = "" | ( "/" path )
  path      = lsegment *( "/" lsegment )
  lsegment  = *lchar
  lchar     = <any TEXT or CTL except "/">

Doesn't seem clear to me if PATH_INFO should be "" or "/" when requesting root paths, but from what I can see both values are valid. Maybe Werkzeug's strict_slashes shouldn't redirect for root URLs for applications mounted at root (is the latter possible to detect?).

[hrkfdn]

The WSGI PEP 3333 states the following:

PATH_INFO
The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.

So it probably should not redirect in this case.

[davidism]

It's saying that it may be, not must be.

[hrkfdn]

Correct, I never stated otherwise. The OpenBSD webserver is correctly setting (unless I am misinterpreting PEP3333 and the CGI RFC) PATH_INFO to "" for root paths. And assuming that both values are correct for the root path and there are webservers sending both values, wouldn't it be reasonable to not redirect in this case? It's clearly causing a problem. If it may be either, it probably shouldn't be forced to have "/" by strict_slashes.

[davidism]

The solution here is to turn off strict slashes for that route then. I don't want to add special cases for specific servers or urls.

[hrkfdn]

The (imo) better solution would be to have strict_slashes, a default option, not break with parameters considered valid by standards, but obviously it's up to you.