adapter.http: remove trailing slashes from routes #50
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This removes trailing slashes (and redirects to paths with trailing slashes) from the API and makes it compatible with the PCF2 showcase and other webapps. Previously, all routes were implemented with a trailing slash, e.g. `/submodels/` instead of `/submodels`. While the API spec only specifies the routes without a trailing slash, this has the advantage of being compatible with requests to the path with a trailing slash and without trailing slash, as werkzeug redirects requests to the slash-terminated path, if available. However, this poses a problem with browsers that make use of [CORS preflight requests][1] (e.g. Chromium-based browsers). Here, before doing an actual API request, the browser sends an `OPTIONS` request to the path it wants to request. This is done to check potential CORS headers (e.g. `Access-Control-Allow-Origin`) for the path, without retrieving the actual data. Our implementation doesn't support `OPTIONS` requests, which is fine. After the browser has received the response to the preflight request (which may or may not have been successful), it attempts to retrieve the actual data by sending the request again with the correct request method (e.g. `GET`). With our server this request now results in a redirect, as we redirect to the path with a trailing slash appended. This is a problem, as the browser didn't send a CORS preflight request to the path it is now redirected to. It also doesn't attempt to send another CORS preflight request, as it already sent one, with the difference being the now slash-terminated path. Thus, following the redirect is prevented by CORS policy and the data fails to load. By making the routes available via non-slash-terminated paths we avoid the need for redirects, which makes the server compatible with webapps viewed in browsers that use preflight requests. Requests to slash-terminated paths will no longer work (they won't redirect to the path without trailing slash). This shouldn't be a problem though, as the API is only specified without trailing slashes anyway.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This removes trailing slashes (and redirects to paths with trailing slashes) from the API and makes it compatible with the PCF2 showcase and other webapps.
Previously, all routes were implemented with a trailing slash, e.g.
/submodels/instead of/submodels. While the API spec only specifies the routes without a trailing slash, this has the advantage of being compatible with requests to the path with a trailing slash and without trailing slash, as werkzeug redirects requests to the slash-terminated path, if available.However, this poses a problem with browsers that make use of CORS preflight requests (e.g. Chromium-based browsers). Here, before doing an actual API request, the browser sends an
OPTIONSrequest to the path it wants to request. This is done to check potential CORS headers (e.g.Access-Control-Allow-Origin) for the path, without retrieving the actual data. Our implementation doesn't supportOPTIONSrequests, which is fine.After the browser has received the response to the preflight request (which may or may not have been successful), it attempts to retrieve the actual data by sending the request again with the correct request method (e.g.
GET). With our server this request now results in a redirect, as we redirect to the path with a trailing slash appended. This is a problem, as the browser didn't send a CORS preflight request to the path it is now redirected to. It also doesn't attempt to send another CORS preflight request, as it already sent one, with the difference being the now slash-terminated path. Thus, following the redirect is prevented by CORS policy and the data fails to load.By making the routes available via non-slash-terminated paths we avoid the need for redirects, which makes the server compatible with webapps viewed in browsers that use preflight requests. Requests to slash-terminated paths will no longer work (they won't redirect to the path without trailing slash). This shouldn't be a problem though, as the API is only specified without trailing slashes anyway.
@aorzelskiGH This fix might be of interest to you, feel free to retest once merged. This issue was noticed as part of testing done at and after the IDTA Plugfest.