Fork me on GitHub

@weavejester would you mind changing the default for :absolute-redirects to false for both site-defaults and api-defaults ? The original HTTP spec that mandated this has been replaced by a newer version about 8 years ago. See and


relevant section from ring-defaults readme: > • :absolute-redirects - Any redirects to relative URLs will be turned into redirects to absolute URLs, to better conform to the HTTP spec. And the code:

   :responses {:not-modified-responses true
               :absolute-redirects     true


FWIW, at work, our default middleware stack turns this off because we're behind a load balancer where it is HTTPS to the LB and HTTP between the LB and our app servers. :absolute-redirects true breaks that.


Exactly. And I don't see the reason for keeping the current default since HTTP spec was updated 8 years ago

Serafeim Papastefanos09:04:52

hey friends! I'm trying to use the wrap-reload middleware. I've defined my app in a variable and try to run it like (wrap-reload app) however it ain't working. I need to pass it like (wrap-reload #'app) can somebody explain to me why i need to do this? is this needed in other middleware also ?


Sounds like the problem is that while the wrap-reload will reload the namespaces, it cannot actually change it's own handle to the handler. So if your changes are in other namespaces, or perhaps just outside the handler in the same namespace (that is, your handler is calling other functions), those references will get updated. But the actual handler will not.


And in contrast, if you use #'app you probably don't even need the reload middleware (that depends a bit on how the namespaces have been constructed)


Phrasing differently, writing (wrap-reload app) means "Take the current version of app, and use that. Forever." while (wrap-reload #'app) means "Whenever you actually call app, check what is the current definition"


We use jetty/ring so that we simply re-evaluate whatever we are editing (function, file), without using that middleware, tools.namespace, or restarting the jetty

Serafeim Papastefanos09:04:35

you mean you start the server from the repl and re-evaluate it fromt he repl ?


We don't re-evaluate the server, just whatever function in some namespace that we are changing


Or rarely the actual main app, if we are changing routing (adding a new endpoint or something)

Serafeim Papastefanos09:04:51

yes yes that's what i mentioned...

Serafeim Papastefanos09:04:54

yes that makes sense

Serafeim Papastefanos09:04:11

however i also want to be able to do it if i run the server from the command line

Serafeim Papastefanos09:04:27

without using the repl at all; just by changing directly some files


Well, yes. This assumes that you need a repl, though one is included in clojure by default (the socket repl). If you want to edit simply any file with something that is not aware of clojure, then you need some other tooling. But even then, if you actually modify app, not just something app calls, you need the explicit var syntax since the server isn't re-evaluated


Other option would be to have something that closes the running server and defines and starts a new one. That is very common too, using integrant, mount etc

Serafeim Papastefanos09:04:55

yes yes i understand thank you

Serafeim Papastefanos09:04:10

no using the wrap-reload seems to be fine for now


I'm not sure if ns-tracker (what the middleware uses) unloads the old versions of the namespaces, though

Serafeim Papastefanos09:04:04

will this bea problem ?


In practice this means that if you delete a helper function, your server will keep working since the old definition is still there, but will break upon a cold restart. tools.namespace in contrast unloads the old version before loading the new, so such bugs are caught


You're welcome