Using Wireshark I noticed that Payara 5.2022.1 redirects HTTP requests originally sent to /path (without slash at the end) using 301 to /path/ (with slash at the end). I wonder what the reasons for that is, because my JAX-RS resource actually is located at <context-root>path</context-root>, @ApplicationPath(""), @Path(""), hence at /path (without slash at the end). Can I somehow stop Payara from asking all clients to do this useless and time-consuming detour?
Hi @mkarg,
This is the default behaviour of Payara, the development team have previously discussed this issue and are of opinion that nothing can be done about this as it has further design implications.
There is no way to disable this behaviour in Payara, you can instead consume ‘/path/’ instead of ‘/path’ to avoid the redirect you have observed.
Best Regards,
James
It would be nice if that behavior would be prominently told somewhere. While it is perfectly compliant with RFCs, it is rather surprisingly, and implies useless delays. In fact, it is really sad that it cannot be changed in Payara, as modifying the client just for the sake of Payara internals makes the client Payara-specific. In case the client shall also work with other servers, and given those servers behavior is oppsite (like snipping away trailing slashes) the client developer is screwed. Hence I really propose to make this behavior configurable in Payara. Thanks.
BTW, there was a discussion on the JAX-RS mailing list whether we support differenciation of slash and no-slash in Jakarta REST. In the past, we agreed to handle it the same whay. In future we MAY break backwards compatibility with 4.0, so Payara then needs to get modified anyways.
I like to amend that the behaviour of Payara is rather inconsistent. As Wireshark told me, /path is redirected to /path/, but /path/subpath actually is not. This is pretty weird and inconsistent. Users apparently cannot guess when the slash at the end is needed and when it is not. This makes using Payara really confusing, and error-prone.