Why "Please enter a valid web address."?

Hi

When editing an event in Garmin Connect Web and entering a link for Website in Additional Information: 

Inputting "">maps.app.goo.gl/St2xpjoDofz33QJW8" yields "Please enter a valid web address." but inputting "">https://www.google.com" works fine.

 

The first one is a valid web address though. This worked previously but is not working any longer.

Why? What to do? It was very convenient to store the parking spots with a link to Google Maps.

Thanks!

Top Replies

  • Why? What to do?

    Probably because the access to the redirect at Google is somehow protected against bots, hence Connect cannot verify its validity. However, when you open the page, copy the…

All Replies

  • Why? What to do?

    Probably because the access to the redirect at Google is somehow protected against bots, hence Connect cannot verify its validity. However, when you open the page, copy the full address of the map, and paste it into the field in Connect, it works.

  • I wonder if Garmin is now blacklisting certain domains, including popular link-shortening services.

    - bit.ly/* is also rejected (e.g. https://bit.ly/1sNZMwL and https:/bit.ly are rejected). Obviously https://bit.ly is just the home page for the service, it doesn't redirect to anything itself. So it's not redirection per se that causes Garmin to reject the link

    - tinyurl.com/* is rejected

    - pastebin.com/* is rejected (this doesn't even redirect to anything, although it has annoying ads, and is apparently being flooded by spam posts from bots)

    But:

    - youtu.be/* is not rejected. I will guess that this is because youtu.be links are always redirected to youtube.com, so it's not like goo.gl which (used) to be a service for shortening arbitrary urls (now it's just for google apps, like maps)

    Speaking of validity, it doesn't even matter if the url actually points to anything or not:

    - w.com is not rejected

    - sdf.sdf is not rejected

    So I'm guessing it's for liability purposes. They don't want to be responsible for the user opening unexpected content. At the same time, they don't appear to be actually checking whether the ultimate destination exists at all.

    Probably because the access to the redirect at Google is somehow protected against bots, hence Connect cannot verify its validity.

    I do think it's a simple domain / keyword blacklist, as I used an obscure link-shortening service to shorten OP's url, and Connect accepts it.

    https://smplu.link/maGCg 

    I saved the event and Connect happily opens the link when I click on it. 

    As you pointed out, the easiest thing to do is open the original link in a browser and copy the full URL of the page that you end up on.