Common URL Problems in Java and their solutions

URLs are everywhere, but it seems that developers don't really understand them, because on stack overflow it's often seen that someone is asking how to create a URL correctly. Want to know how the URL syntax works, you can look at the Brother Lian Education (Www.lampbrother.net) summarized this article, very good.

This article does not delve into the full syntax of URLs, which is a Java library that we publish to correctly create URLs.

The urlencoder of the problem 1:java

Not only does this class have a bad name, but the first sentence on its document is not quite right.

Utility class for HTML form encoding.

You may be wondering why it's called Urlencoder, and it's completely silent to see this line.

If you've read the Www.lampbrother.net blog post, now you should understand that you can't magically turn a URL string into a secure, properly coded URL object through this class, but if you don't do your homework, here's a small example to help you understand.

Suppose you have an HTTP service endpoint that accepts a query parameter P,p value is the string to look for. If you search for "You & I" This string, the URL of the search you created for the first time may be this:. This is certainly not working, because & is the delimiter separating the query parameter name/value. If you get the URL string of the disorder, you can do nothing about it, because first you can't parse it correctly.

Well, let's use the Urlencoder. Urlencoder.encode ("You & I", "UTF-8") is the result of you+%26+i. This%26 decoding is &, and the + number in the query string represents the space, so this URL is working properly.

Now suppose you want to use your query string to stitch the URL path instead of the URL parameter. Obviously, it's wrong. Unfortunately, the result of Urlencoder.encode () is also wrong. Decoding will get/search/you+&+i, because the + number in the URL path is not resolved to a space.

Urlencoder may be able to meet some of your scenarios. Unfortunately, its overly generic name makes it easy for developers to misuse it. So the best way to do this is not to use it, lest other developers make mistakes when they use other functions on your basis (unless, you're really doing "HTML form coding").

Question 2:groovy Httpbuilder and the URI of Java

HTTP Builder is an HTTP client library for groovy.

Creating a normal GET request is simple:

New Httpbuilder.request (Method.get) {

Uri.path = "/foo"

}

This code will send Get/foo http/1.1 to the server (you can run Nc-l-P 18080 before performing this code verification).

Let's try a URL that contains spaces.

New Httpbuilder.request (Method.get) {

Uri.path = "/foo Bar"

}

This is Get/foo%20bar http/1.1, and it looks good.

Now suppose that one of our paths is called Foo/bar. This can not simply send Foo/bar is over, because this will be considered as the path contains two paragraphs, Foo and bar, then we try to Foo%2fbar bar (replace/substitute the corresponding code).

New Httpbuilder.request (Method.get) {

Uri.path = '/foo%2fbar '

}

This is sent by Get/foo%252fbar http/1.1. That's not good. The% in the%2f is repeatedly encoded, so that the decoded path is Foo%2fbar instead of Foo/bar. The real thing to blame here is Java.net.URI, because it's the UriBuilder class in this httpbuilder.

The type of URI attribute exposed in the configuration closure in the preceding code is uribuilder. If you pass Uri.path = ... To update the URI's Path property, it will eventually invoke a constructor of the URI, which is described in this way for the incoming path property:

If the path parameter is supplied, it is appended to the URL. The characters in path are encoded as long as they are not non-reserved, punctuation, escaping, and other characters that are described in detail in RFC 2396, but not/or @.

This does not make much sense, because if the text before the code contains special characters, it cannot generate a correctly encoded path fragment. In other words, "I will encode this string and it is correct after encoding," which is of course a fallacy, and the URI is just the victim of this fallacy. If the string has been correctly encoded, then it's fine, if not, then it's over, because the string can't be parsed. In fact, the document does not mean to escape the meaning that it assumes that the path string has been correctly encoded (that is, using/to separate the path correctly), and that it has not been correctly encoded (except that the other parts of the/are still required to encode).

If Httpbuilder does not use this flawed feature of the URI class, of course, it would be better if the URI itself was no problem.

The right approach

We wrote this url-builder, which can help developers to easily stitch various types of URLs. It follows the coding specifications in the first few references, and it also provides streaming APIs. The following example can be used to cover almost all usage scenarios:

Urlbuilder.forhost ("http", "foo.com")

. PathSegment ("with Spaces")

. Pathsegments ("path", "with", "VarArgs")

. PathSegment ("&=?/")

. Queryparam ("Fancy + Name", "Fancy?=value")

. Matrixparam ("Matrix", "Param?")

. Fragment ("#?=")

. Tourlstring ()

This example shows the different encoding rules for each part of the URL, for example, the &= is allowed in the path, while the/is required to be encoded, but in the query parameter = It needs to be encoded, but the number is not needed because it is already part of the query string.

Common URL Problems in Java and their solutions