Request Map doesn't contain information about authority about http-kit HOT 8 CLOSED

@RokLenarcic Hi Rok, can you please clarify if you're talking here about http-kit client or server? It might be helpful for you to provide an example snippet.

Cheers!

from http-kit.

http-kit server.

The example is very simple. Run an http-kit server and use an http client such as clj-http to request an URL with a user and password in url.

(clj-http.client/get "http://user:pass@localhost:4000")

The request map in the handler, constructed by http-kit server, has no information about the supplied user and pass data.

from http-kit.

And to clarify- you'd expect the user and pass data to be automatically extracted from the request URI and placed in the Ring request map?

Is there a precedent for that with other Ring servers?

from http-kit.

Yes. I haven't really tested other Ring servers, but I am working with several products that use that feature, implemented in a variety of languages. It seems wrong for that information to just get lost.

from http-kit.

It seems wrong for that information to just get lost.

Unless I'm missing something, I'm not sure that this characterization is accurate though- you seem to be implying that the information is present then being stripped/lost. But you of course still have access to the full URI in the Ring request map, it just hasn't been automatically parsed to extract the username and password.

Trying to automatically parse something like this at the server-level for all requests wouldn't make sense since you'd be imposing a non-trivial cost on all requests.

Instead, I'd expect one of the following to make more sense:

1. Manually extract the info in handlers that need it.
2. Use an appropriate Ring middleware.
3. Use an appropriate route-matching destructuring.

Relatedly, I'd note that providing credentials in URIs like this is rarely a good idea. I'd expect credentials to more commonly be provided via request params.

from http-kit.

It is being stripped/lost. We do not have access to full URI in ring request map.

Here's the code:

(defn rrr [req] (clojure.pprint/pprint req))
(server/run-server #'rrr {:port 3003})

And this is what is printed when I do:

(clj-http.client/get "http://R:L@localhost:3003")

Here's the printout:

{:remote-addr "127.0.0.1",
 :headers
 {"accept-encoding" "gzip, deflate",
  "authorization" "Basic UjpM",
  "connection" "close",
  "host" "localhost:3003",
  "user-agent" "Apache-HttpClient/4.5.13 (Java/14.0.2)"},
 :async-channel
 #object[org.httpkit.server.AsyncChannel 0x69b91012 "/127.0.0.1:3003<->/127.0.0.1:57266"],
 :server-port 3003,
 :content-length 0,
 :websocket? false,
 :content-type nil,
 :character-encoding "utf8",
 :uri "/",
 :server-name "localhost",
 :query-string nil,
 :body nil,
 :scheme :http,
 :request-method :get}

This doesn't contain full URL or anything, the data is just gone. It's the same with fragments such as:

(clj-http.client/get "http://R:L@localhost:3003?a=1#frag")

That ending #frag is just gone.

{:remote-addr "127.0.0.1",
 :headers
 {"accept-encoding" "gzip, deflate",
  "authorization" "Basic UjpM",
  "connection" "close",
  "host" "localhost:3003",
  "user-agent" "Apache-HttpClient/4.5.13 (Java/14.0.2)"},
 :async-channel
 #object[org.httpkit.server.AsyncChannel 0x5d15fc6c "/127.0.0.1:3003<->/127.0.0.1:57384"],
 :server-port 3003,
 :content-length 0,
 :websocket? false,
 :content-type nil,
 :character-encoding "utf8",
 :uri "/",
 :server-name "localhost",
 :query-string "a=1",
 :body nil,
 :scheme :http,
 :request-method :get}

from http-kit.

Thanks for providing an example, that's helpful 👍

We do not have access to full URI in ring request map.

I see, didn't realise that.

So it looks like credentials in URLs like this are typically stripped from the URL and instead used to populate the "authorization" header you're seeing (encoded) in your printouts.

I suspect this might be for security reasons. Not sure off-hand where the stripping actually occurs, but seems plausible that it may actually be the http client doing the stripping.

Anyway the http-kit server behaviour here seems to be consistent with the standard Ring Jetty server.

So it seems your choices would be either to decode the "authorization" header value, or to provide the credentials via a query string or (ideally) params.

It's the same with fragments such as: (clj-http.client/get "http://R:L@localhost:3003?a=1#frag")

Are fragment ids typically transmitted to web servers? I was under the impression that fragment ids are intended only for client-side use - so would expect clients to strip these.

Anyway the http-kit server seems to again be consistent here with the standard Ring Jetty server.

from http-kit.

Alright I can work with the header.

from http-kit.