renderHeaders assumes rawPathInfo is an absolute path

[jfischoff]

When renderHeaders creates a request it assumes rawPathInfo is a absolute path. If it is a relative path the Request-Uri part of the HTTP request will be invalid.

I don't think wai makes any guarantees about the rawPathInfo so I don't think http-reverse-proxy should either.

I think renderHeaders should use the logic in http-client http://hackage.haskell.org/package/http-client-0.5.14/docs/src/Network.HTTP.Client.Request.html#local-6989586621679091539

Here is the logic I am referring to:

            <> (case S8.uncons $ path req of
                    Just ('/', _) -> fromByteString $ path req
                    _ -> fromChar '/' <> fromByteString (path req))

[snoyberg]

How can rawPathInfo not be an absolute path? It's taken from the HTTP request header.

[jfischoff]

One can set it to anything

…

On Sun, Mar 31, 2019 at 9:30 AM Michael Snoyman ***@***.***> wrote: How can rawPathInfo *not* be an absolute path? It's taken from the HTTP request header. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKSO-FueBq1J1-XabqnDQKv_-7KVYM4ks5vcOK-gaJpZM4cS4Yg> .

[snoyberg]

Right, I get that, I'm just not sure what the case is where that will actually happen. Anyway, if you'd like to PR a fix, I'll be happy to review.

[jfischoff]

The use case for use is a proxy that rewrites the path. The issue is no where did we see that the path must be absolute and it works fine if it regular HTTP and not websockets. I could see changing the Wai doc to say it must be absolute as an alternative. 🤷‍♂️

[jfischoff]

I can also one day add a PR assuming inspiration hits me :p