12

Consider the following link:

https://doc-0g-bc-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/9la5prt2u93men2ft6831kkki73u94n0/1403496000000/02058467015715614041/*/0ByTrbPQHgxJddnBTSlUxZVNBOG8?h=16653014193614665626

If I try to include it as a link in this post using the "displaced URL" syntax (link), the href of the resulting <a> (in the output, not the markdown) gets converted to:

https://doc-0g-bc-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/9la5prt2u93men2ft6831kkki73u94n0/1403496000000/02058467015715614041/%2a/0ByTrbPQHgxJddnBTSlUxZVNBOG8?h=16653014193614665626

If you scroll to the right, you will see that the difference is that * in the URL has been %-encoded to %2a. But here is the problem: the version of the URL with the * goes to the right place (here is a link from a shortener: link - you should get a PDF of the Ramayana), while the link above, which has %2a, does not.

I'm not sure whether this is a bug in SE or in Google, but even if it is a bug at Google, it would probably be a good idea for SE to have a workaround for it.

Note also: If I try to use a literal <a> tag in my post to include the link, it fails to render: (link). The same URL with the * removed links just fine using a literal <a> tag (link) (albeit there's nothing at that URL), so this is probably a symptom of the same underlying problem.

Improve this question
8
  • This may also be a bug on the googleusercontent.com server though; any character, even though unreserved, SHOULD be supported as encoded and unencoded (with SHOULD interpreted in the RFC sense).
    – Martijn Pieters
    Commented Jun 23, 2014 at 8:04
  • Maybe I'm reading the RFC wrong, but it also says "Percent-encoding a reserved character, or decoding a percent-encoded octet that corresponds to a reserved character, will change how the URI is interpreted by most applications.", which seems to indicate that servers are not required to interpret the %-encoded equivalent of a reserved character as equivalent to the character.
    – senshin
    Commented Jun 23, 2014 at 8:06
  • Right, I do admit only looking at the Wikipedia interpretation as a short-cut here. I am trying to find a similar bug fixed not too long ago, but it is eluding me right now.
    – Martijn Pieters
    Commented Jun 23, 2014 at 8:14
  • I've seen encoding also with url fragments changing from #Whatever::text (an anchor in an api) to #Whatever%3A%3Atext - quite annoying. Even if it breaks the spec, it would be better to escape html characters and use the url as input by the user.
    – AD7six
    Commented Jun 23, 2014 at 9:03
  • 1
    You should have copied the next sentence as well. "If a reserved character is found in a URI component and no delimiting role is known for that character, then it must be interpreted as representing the data octet corresponding to that character's encoding in US-ASCII." HTTP URIs use the generic syntax, which explicitly says it's not using the sub-delims. My interpretation of that is safe to percent-encode an asterisk. That said, it may be worth changing it anyway, if even Google is (illegally, as far as I can tell) treating the two differently.
    – balpha StaffMod
    Commented Jun 24, 2014 at 14:44
  • @senshin That bit of the RFC is saying that the reserved character will lose its special meaning when encoded, which is generally the reason why you encode it (e.g. to prevent & from delimiting parameters in the query string). But if the character has no special meaning in the first place, there's nothing to change; after decoding it, it will be treated as the same literal character as it would have if not encoded in the first place.
    – Barmar
    Commented Jun 25, 2014 at 16:27
  • @Barmar I see. I guess this might be a bug on Google's end rather than SE's end, then. But if even Google makes mistakes like this, it may still be worth working around.
    – senshin
    Commented Jun 25, 2014 at 21:54
  • @balpha And archive.org has the same issue :(
    – Tim Stone
    Commented Jun 25, 2014 at 22:12

0

Reset to default

Browse other questions tagged .