Why is HTTP :remote-addr sometimes nil?

[Phill Wolf]

Sometimes, the Ring handler observes a nil :remote-addr in the request.

The REPL exercise below can demonstrate the phenomenon. Start the server;
go to a web browser, visit the page, and lean on the Refresh button for a
while; then return to the REPL and look at the atom that counts nil
:remote-addr.

I expected :remote-addr to be non-nil (after all, the request came from
somewhere), so I am not sure what this means.

I used [aleph "0.4.1-beta3"] and Firefox.

Here is the REPL exercise:

(ns simplest-server
(:require [aleph.http :as http]))

(def nils (atom 0))

(defn handler-slow [req]
(Thread/sleep 1000)
(when (nil? (:remote-addr req))
(swap! nils inc))
{:status 200
:headers {"content-type" "text/plain"}
:body "hello!"})

(comment

@nils

;; Serves slowly.
;; Auto-repeat the browser Refresh for a while, then check @nils.
(def listening
(http/start-server handler-slow {:port 8080}))

(.close listening)

@nils

)


As an alternative, I tried testing :remote-addr before the Thread/sleep. I
did not observe any nils. I infer that :remote-addr is mutable or subject
to some kind of race condition. The request map appears to be a facade on
Netty's HttpRequest and Channel, defined by (p/def-derived-map
NettyRequest...), so perhaps other members are mutable too?

[Zach Tellman]

It appears that some part of this chain is failing:
https://github.com/ztellman/aleph/blob/master/src/aleph/http/core.clj#L201.
I'm not sure which part, offhand, but one possibility is that if you call
this after the connection has already closed then it no longer has the
information needed to resolve the address. There's no mutability, per se,
but the laziness may be causing some sort of race condition.

I'll take a closer look and see if I can figure out a solution.

Post by Phill Wolf
Sometimes, the Ring handler observes a nil :remote-addr in the request.
The REPL exercise below can demonstrate the phenomenon. Start the server;
go to a web browser, visit the page, and lean on the Refresh button for a
while; then return to the REPL and look at the atom that counts nil
:remote-addr.
I expected :remote-addr to be non-nil (after all, the request came from
somewhere), so I am not sure what this means.
I used [aleph "0.4.1-beta3"] and Firefox.
(ns simplest-server
(:require [aleph.http :as http]))
(def nils (atom 0))
(defn handler-slow [req]
(Thread/sleep 1000)
(when (nil? (:remote-addr req))
(swap! nils inc))
{:status 200
:headers {"content-type" "text/plain"}
:body "hello!"})
(comment
@nils
;; Serves slowly.
(def listening
(http/start-server handler-slow {:port 8080}))
(.close listening)
@nils
)
As an alternative, I tried testing :remote-addr before the Thread/sleep.
I did not observe any nils. I infer that :remote-addr is mutable or
subject to some kind of race condition. The request map appears to be a
facade on Netty's HttpRequest and Channel, defined by (p/def-derived-map
NettyRequest...), so perhaps other members are mutable too?
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.