This repository has been archived by the owner on Sep 1, 2022. It is now read-only.
Fix for Github issue #272 #274
Merged
Conversation
This file contains 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
The problem was that java.net.URI and java.net.URL could not parse url strings that were based on backslash escape rather than %xx escape. The General Rule is this: 1. any url given to e.g. HTTPSession or HTTPMethod or HTTPFactory is assumed to be the url that is wanted on the server side. 2. #1 means that, again as a general rule, urlstrings given to those classes should not be %xx escaped unless that is what you want on the server side. 3. The key to understand is that a. those classes will internally %xx encode the url string they are given even if the url string already is %xx encoded. b. on the server side, the %xx encoding will be performed on the incoming url string. This means that the %xx encoded string you originally sent is the one given to the servlet. Bottom line: do not do %xx encoding yourself unless your server side code is expected to see a %xx encoded url. Anyway, the fix is to create a procedure -- HTTPUtil.parseToURI() -- that can properly create a java.net.URI object from a backslash escaped url string. Any time you need to create a URI object, you should do so using that procedure.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The problem was that java.net.URI and java.net.URL
could not parse url strings that were based on
backslash escape rather than %xx escape.
The General Rule is this:
or HTTPFactory is assumed to be the url
that is wanted on the server side.
given to those classes should not be %xx escaped
unless that is what you want on the server side.
a. those classes will internally %xx encode the url string they are
given even if the url string already is %xx encoded.
b. on the server side, the %xx encoding will be performed
on the incoming url string. This means that the %xx encoded
string you originally sent is the one given to the servlet.
Bottom line: do not do %xx encoding yourself unless your server side
code is expected to see a %xx encoded url.
Anyway, the fix is to create a procedure -- HTTPUtil.parseToURI() --
that can properly create a java.net.URI object from a backslash
escaped url string. Any time you need to create a URI object,
you should do so using that procedure.
Misc. Notes:
-- Test program TestURIParse is also included.
-- In several places, I changed the use of URL to URI
so this new code could be used. The primary effect was
to replace MalFormedURLException with URISyntaxException
in many places.
-- minor unrelated fix to TestFormBuilder is also included in this pull request:
changed port numbers for the tests.