[#TK-83] Unable to serve content at endpoint registered in add

advertisement
[TK-83] Unable to serve content at endpoint registered in add-ring-handler as
Jetty9 automatically does a 302 to endpoint + trailing slash Created: 2014/09/17 Updated:
2015/03/21 Resolved: 2014/10/08
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Resolved
Trapperkeeper
None
None
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
New Feature
Melvin Zhang
Fixed
None
Not Specified
Template:
Epic Link:
Story Points:
Sprint:
customfield_10700 true
3.4 Green MVP
1
PE 2014-10-08, PE 2014-10-22
TK-JETTY9 0.8.0
Priority:
Assignee:
Votes:
Normal
Unassigned
0
Not Specified
Not Specified
Description
Currently when registering a handler using (add-ring-handler handler "/api/resource"), Jetty9
issues a 302 redirect when requesting http://server.com/api/resource to
http://server.com/api/resource/ (with the trailing slash)
This makes it difficult to create a REST API endpoint at /api/resource (without trailing slash). A
workaround is to change the endpoint to a higher level such as "/api", but this is not a good fix
as all resources under /api will have the same endpoint.
A better fix is to disable the automatic 302 from Jetty by calling setAllowNullPathInfo(true) for
the context handler. This can be exposed as a web server configuration option.
Comments
Comment by Christopher Price [ 2014/09/18 ]
Awesome, thanks for the tip! We'd noticed that annoyance in the past but hadn't had time to
figure out a proper fix. Will get this onto the roadmap.
Comment by Christopher Price [ 2014/09/18 ]
I think we might even set this to `true` by default. Would anyone have any concerns about that?
Comment by William Crighton [CCC] [ 2014/09/21 ]
First issue I'm reading, first comment I'm adding, first thought it produced (after reading your
last comment) - merely this:
Please make sure to document the default and behavior it produces in a way that folks searching
for a fix to the automatic 302's being thrown have a reasonably decent chance of hitting the
documented behavior and can figure out what to do.
Of course, I add this comment in complete ignorance of your documentation behavior and feel
this little itch between my shoulder blades – the tell that I'm speaking to those who already
know. Still, just trying to help.
-wc
Comment by Christopher Price [ 2014/09/21 ]
Sure, thanks for the comment. It seems to me that the most intuitive default behavior would be
for it to not do a redirect, so I'm leaning towards making that the default. We'd then provide an
override setting that allowed people to turn that redirect behavior back on if that was their
preference. The new setting will be documented alongside all of the existing settings, here:
https://github.com/puppetlabs/trapperkeeper-webserver-jetty9/blob/master/doc/jetty-config.md
Comment by Christopher Price [ 2014/09/21 ]
Preben Ingvaldsen if you get bored this week, here's a good ticket
Generated at Tue Feb 09 20:41:45 PST 2016 using JIRA 6.4.12#64027sha1:e3691cc1283c0f3cef6d65d3ea82d47743692b57.
Download