Clojurians Log v2

https://github.com/ring-clojure/ring/pull/504

yeah

@weavejester do you want me to do so?

Update the docstring you mean?

Sure

Imma be real, at this point I prefer just making a route for each individual resource

(defn sitemap-xml-handler
  [request]
  {:status  200
   :headers {"Content-Type" "application/xml"}
   :body    (slurp (io/resource "/public/sitemap.xml"))})

["/public/sitemap.xml"
  {:get {:handler sitemap-xml-handler}}]

"I accidentally gave access to my entire classpath including .class files"? No

Potentially I could update the docstring with a warning about making every resource on your classpath public. Or add a warning/precondition in there, as I don't think there's ever a legitimate reason for making your entire classpath public.

A downside to a precondition is that it will break apps. That sounds "good", but not every app is exposed to the public internet. Exposing your entire classpath over http is usually bad, but there are always contexts where "who cares"

I forget the exact args for wrap-resource, but generally you give it a prefix like "public/" and then it will only serve resources from under <classpath root>/public/

a lot of tooling will try and put different things in different directories so you'll have a resources/ directory in the project, so resources/public/ would be the place to put things if you use "public" as the prefix. it all just ends up thrown on the classpath which is why not including a prefix will make it able to serve up source files

Okay!

Thanks, I’m up and running. This seemed less intuitive/less well-documented than it might be, perhaps because I’m not accustomed to java builds and terminology like classpath/resource path. Also seems to be a little bit of friction with shadow-cljs having public as the default/typical build location.

not sure about the shadow-cljs, but assuming you want to serve up the js that is the result of the build then it make sort of make sense

it would just be better if it were resources/public or something

one dirlevel deep so you can use (wrap-resource "public")

but also, I find it strange that it is so easy to end up serving your whole src dir. I am just now realizing I’ve been doing that on anothe project

I'll add support for it in the next Ring version, along with a more flexible way of adding cookie attributes. In the meantime, you could always set the Set-Cookie header directly. Or write middleware to automatically add Partitioned to existing cookies.