I know that this solution looks rather dirty, so it probably would be better to not merge it before discussing it a bit.

I don't think that it is dirty, it looks good to me. The only addition that we might consider is making an option to allow users to disable this feature. I don't know if it makes sense, but perhaps someone wants these white spaces in the URL for some reason.

One observation I can make is that the logic to parse the URL is in func Parse(rawurl string) (*URL, error). So, perhaps it would be better to call the created function func RemoveAsciiTabAndNewlines(s string) string in it. Also, since the created function isn't called anywhere else, wouldn't it be better to make it private? Feel free to correct me if I'm wrong.

Also, since the created function isn't called anywhere else, wouldn't it be better to make it private?

Yes. I initially left it exported because I wanted to use it in my code as well: Request.AbsoluteURL doesn't report errors (which sadly can't be fixed without breaking API), so I had to normalize and resolve relative URLs myself.

In any case, I agree that it's better not add more exported functions without good reason. I can live with this function copy-pasted until v3 comes and fixes the API issues that require me to call this function myself to begin with :).

The only addition that we might consider is making an option to allow users to disable this feature. I don't know if it makes sense, but perhaps someone wants these white spaces in the URL for some reason.

I believe they should never appear in URL in unescaped forms, and this code doesn't touch their escaped forms. In theory someone might have use cases insane enough to rely on that some servers do accept unescaped tabs AND might treat them differently than escaped ones, but I'd argue that in this scenario he better use custom code instead of generic crawler framework.

EDIT: I'll add some test cases for escaped versions, just in case.

I understand, that servers don't accept these urls, but what if someone wants to create a checker that displays malformed urls?

I understand, that servers don't accept these urls, but what if someone wants to create a checker that displays malformed urls?

This PR doesn't touch HTML attributes, so it doesn't prevent one from inspecting ther original values. Tabs and newlines are stripped only when calling Visit and related methods. (if I get your question right)

My bad, you are right. Please fix the golint issues and it's ready to merge

@WGH- could you rebase this PR?

Sorry, I forgot to update the status of this PR. With #673, this PR is no longer necessary.