@danielcompton I created https://github.com/clojars/clojars-web/pull/923 to move us off of Jetty 11 and on to http-kit. It uses a https://github.com/clojars/http-kit that supports custom status messages. I don't know if that is worth trying to get added upstream, as they are deprecated in HTTP/1.1, and we want to move away from using them with https://github.com/clojars/clojars-web/issues/911.
I created a net.clojars.internal group for forks like this and added you to it as an admin.
I'm a bit confused: if they're deprecated and you want to move away from them, why switch away from Jetty?
Jetty 11 is EOL, and has CVEs. I tried to get our hack for them to work with Jetty 12, but could not, and couldn't figure out why it wasn't working. So it was easier to patch http-kit for now. Once we stop using custom status messages, we can move to the official http-kit releases.
Or move to Jetty 12?
(which was really what I meant -- drop custom status messages and upgrade to Jetty 12)
I tried Jetty 12, as I said
ah
we can't drop custom status messages yet, as it requires changing pomegranate, then getting libs/tooling to upgrade to that new pomegranate version. Otherwise, we can't signal deploy issues to deploying users.
And using Jetty over http-kit doesn't really do anything for Clojars other than require us to address CVEs.
Ah, so the move to a patched http-kit is to avoid a lot of other work that you can push off "indefinitely"... I wasn't sure how much work the "drop custom status messages" piece was 🙂
(what we did at work was provide the "custom status message" as a plain text body for these failure HTTP status values, so we had not encountered this issue)
yes, exactly. I'm going to implement problem details in the next week or so, and submit patches upstream to projects to make the needed changes to be able to use them, but we may have to wait a while to drop the custom status messages.
The issue is the maven wagons/transports have limitations on how we can send this information to the client and have it displayed. For the HTTP wagon, the status message is the only way. The HTTP transport supports problem details, but pomegranate uses the old HTTP wagon instead of the newer HTTP transport. It should be a simple change in pomegranate, I just need to do it.