I've received complaints that the links that my software is generating aren't following the W3C URL-specification. http://www.w3.org/Addressing/URL/url-spec.txt

The links generated looks like this: https://organization.proxive.se/proxive/https://www.google.com/

The software is a proxy and generates the links this way so that the proxy doesn't have to parse relative links. Examples: /maps/, ../relative_link.

Using a solution that uses query-string wouldn't allow this.

Is my usage correct of constructing the URL correct or should I URL encode everything after /proxive/?

I can add that my solution works in all major browsers.

  • If you encode everything after/proxive then will W3c allow it? Commented Dec 18, 2014 at 9:50
  • Well that is my question. "Is my usage correct of constructing the URL correct or should I URL encode everything after /proxive/?" Commented Dec 18, 2014 at 9:54
  • A bit of an aside, but I'm curious... why wouldn't "a solution that uses query-string .. allow this"? Isn't what you are doing essentially the same as a query string, as I assume you are manually parsing the URL and passing this path segment to your application? (You could even be URL rewriting this URL to one with a query string?)
    – MrWhite
    Commented Dec 18, 2014 at 11:40
  • 1
    Since if a user clicks a relative link it will ignore the path in the query string. Example: User is on https://organization.proxive.se/proxive/?url=https://www.google.com/ and clicks a relative link to ./hello/world/. The user ends up on https://organization.proxive.se/proxive/hello/world/ instead of https://organization.proxive.se/proxive/?url=https://www.google.com/hello/world/ Commented Dec 18, 2014 at 14:42
  • Ah I see, but how do you handle the situation when an alternative BASE URL has been specified in the document? (Or a root-relative URL like @StephenOstermiller mentions - unless perhaps your proxy works in the root of your site?)
    – MrWhite
    Commented Dec 21, 2014 at 0:41

1 Answer 1


It appears that the only thing that you would need to escape in that URL would be the :


Then your URL wouldn't use any disallowed characters and the directories would still be on the sub URL for supporting some relative links.

I just want to point out that not all relative links will work. I usually code my sites to work with site relative URLs like /img/logo.png When used on http://example.com/dir/page.html it will fetch the relative URL http://example.com/img/logo.png.

So in your case if you tried to proxy http://example.com/dir/page.html it would end up fetching https://organization.proxive.se/img/logo.png

  • "you would need to escape ... the :" - although I believe a : is valid in a path segment in an absolute URL. In fact all chars would seem to be valid in the path part. However, I think the confusion lies in the use of the slash, in what is essentially a single path segment? The slash is the path segment delimiter, so cannot be unescaped in a single path segment. The https://www.google.com/ part is really one path segment, as it is being read by the proxy, however, any other system parsing the URL would see this as an additional 3 (maybe 4) path segments on the parent URL. (?)
    – MrWhite
    Commented Dec 21, 2014 at 0:53
  • So, I think, the URL should perhaps (more correctly) be expressed as: https://organization.proxive.se/proxive/https:%2F%2Fwww.google.com%2F (?)
    – MrWhite
    Commented Dec 21, 2014 at 0:55
  • He wants to preserve the slashes in the URL so that some relative URLs work. Commented Dec 21, 2014 at 1:18
  • The proxy knows how to handle relative urls starting with "/". The proxy also knows how to handle if the browser sends one slash instead of the doubleslash in the url. So if the : symbol is valid then I don't have to change anything I guess?! Commented Dec 21, 2014 at 9:03
  • @StephenOstermiller Yes, that should still preserve the slashes, just as encoding the colon will preserve the colon - this URL still needs to be parsed (inc. unescaped) by the proxy, which I assume is what's happening. (Although admittedly, by default, on Apache an encoded slash in the path part will result in an instant 404, so would perhaps need to look into the AllowEncodedSlashes directive if deciding to go this route.)
    – MrWhite
    Commented Dec 21, 2014 at 11:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.