-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return HTTP 308 instead of 301 when URL has trailing slash #2137
Comments
When you execute
Redirecting POST requests is interesting because the HTTP RFC says the user may need to be involved. In case of I'm off two minds about this. Users who don't realize the difference between trailing and no-trailing slash will want the same behaviour. OTOH, there's no definitive answer here and some will argue that the URLs are not the same. I think the current behaviour is acceptable in that the client could retransmit the message the body. |
Most clients (including curl) will change the subsequent request following a 301/302 response to a GET, and that's why the body is dropped. The use of ... < HTTP/1.1 301 Moved Permanently < Location: /v1/data < Date: Mon, 24 Feb 2020 18:32:05 GMT < Content-Length: 0 < * Connection #0 to host localhost left intact * Issue another request to this URL: 'http://localhost:8181/v1/data' * Switch from POST to GET * Found bundle for host localhost: 0x7fea40504ca0 [serially] * Re-using existing connection! (#0) with host localhost * Connected to localhost (::1) port 8181 (#0) > POST /v1/data HTTP/1.1 ... I guess the original purpose of this was something like "you can't POST here any longer, so here's a web page explaining what to do instead" but in the context of serving API clients it almost always makes more sense to serve a 307/308 on a POST redirect. |
I understand the tech behind it, but i think important thing is that, as a user of the API, you will get 200 and completely different document queried (or different decision made - which is super important when doing authorization). Idea posted by @anderseknert seems reasonable. If it's not suitable for you, I'd at least add information about this somewhere in documentation. |
IMO we should probably update to support returning a 308 (307 might be appropriate.. but saying its permanent makes more sense IMO, clients don't need to like re-check.. they should always use the new location). The only part I'm not sure on is whether or not we can safely change the return codes without breaking existing clients. This might require a major version bump for the API if there is concern about backwards compatibility (and from my point of view there is a little bit of concern). |
I hear you, @patrick-east - I used to work on an identity server some years back and we had both the some problem and the same concerns about changing redirect status codes - what we did eventually was that we made the change but made it possible to revert to the old status code using some half-documented feature toggle should anyone need to. We kept this in for a couple of releases, but since nobody seemed to notice or ask about it we eventually had it removed. Might be a way forward. |
We discussed this a bit at the OPA weekly meeting (notes https://docs.google.com/document/d/1v6l2gmkRKAn5UIg3V2QdeeCcXMElxsNzEzDkVlWDVg8/edit#heading=h.2ymp0280bora) The conclusion was that we will not change the return code for the In the meantime we have a few concrete action items we can take to improve the situation, especially for new users of OPA:
|
@patrick-east is there a v2 API in the plans or is that hypothetical? :) We had another developer bitten by this yesterday. With
..the 😱 factor goes up by an order of magnitude. Of course, given proper testing and solid client implementations this might be unlikely to happen in a production setup. It does however give a real shaky impression when this happen in demos and pitches, which is of course the last thing you'd want from an authorization system. |
@anderseknert sorry for the delay! Its mostly hypothetical.. at some point we'll nudge OPA to v1.x.x and we'll have some flexibility to make backwards incompatible changes (there's an issue label for just that.. will add to this issue too).
+1, but I think the key is proper testing and if we can make it more visible when API requests are not doing what is expected. For the trailing slash if we implement the handful of things that came out of the meeting that should go a long ways, and for the missing input value there is discussion around making things like the "console" decision log on by default with the server (and maybe the apache style logs off by default) so that it is easier to see that |
Thanks @patrick-east 👍 Agreed completely on making it more visible and obvious in docs and logs should the current behavior be kept as is. |
This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. |
This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. |
On a short note: This also occurs when an URL has a double slash at some other position, e.g. http://opa.example.com//v1/data/ |
EDIT: The original issue requested OPA ignore trailing slashes (which is a bit controversial). Instead we can change the server to return HTTP 308 instead of HTTP 301.
Expected Behavior
The same result when posting on url with
/v1/data/path/to/document
and/v1/data/path/to/document/
.Actual Behavior
The result is different.
Steps to Reproduce the Problem
POST /v1/data/somePolicy
Result:
POST /v1/data/somePolicy/
Result:
The text was updated successfully, but these errors were encountered: