Google PWS drops URL fragment

[DKMudrechenko]

We have an angular2 application that uses Hash location strategy, so it needs an url fragment to work. The url is then shortened via goo.gl and applied to an eddystone-url beacon.

However when the beacon is detected, both iOS and Android cannot see the fragment, so for example we had www.foo.com/#/12345 and then shortened it. Both systems will only see www.foo.com/. If I use a Physical Web app on Android and switch Physical Web Service setting to "Production Open Source PWS" it displays url with the fragment, so it pointed to Google's PWS, but is it a bug or expected behavior?

This tool also drops url fragment if I try shortened url, but if I test www.foo.com/#/12345 without shortening - everything is ok.

I found this https://github.com/google/physical-web/pull/557/files, can it be related?

[cco3]

If the two URLs have the same title and the same description and only differ in the fragment, they are considered part of the same group. However, if there is only one such beacon around, it should take you to the actual fragment. Are you able to share an example URL I'd be able to test?

[DKMudrechenko]

Here is the example of shortened url: https://goo.gl/4KwnR6 with the actual application, and we have only one eddystone url beacon active.

[cco3]

Hm, this does seem like unexpected behavior. Rui, could you comment on whether or not this is intended?

Specifically, the fragment for https://fyi.reveldigital.com/#/fbe94043-a8d8-4b9c-9209-0e11f628bd60 gets dropped when it goes through this shortened URL: https://goo.gl/4KwnR6
(But it doesn't get dropped when sent to the PWS directly.)

[DKMudrechenko]

Any updates on this?

[scottjenson]

@mmocny @oahziur ?

[oahziur]

Just checked with @mmocny, this is not an intentional behavior, and we are working to resolve.

[mmocny]

Great bug! Did a bit of investigation here, and learned something: Redirects with fragments have weird history.

Luckily, modern browsers have ironed this out and have a pretty rational approach to fragments and redirectors including fragment portion of URL:

• DONT send fragment portion to webserver as part of a GET
• DO hold on to fragment portion of URL, so you can append it to the final URL, locally
• If any redirection URL (e.g. HTTP 3xx with Location: URL) includes a fragment, override your local fragment (replace the old one).

PWS was not doing the last part. We will add it.

---

I created a few tests to confirm what browsers do:

First, create short links with/without a fragment:
https://goo.gl/vcvYc -> https://youtube.com
https://goo.gl/yVlLVD -> https://youtube.com/#foo

Next, create short links to short links, with/without fragment to with/without fragment (e.g. all permutations):
http://bit.ly/2fyCh6F -> https://goo.gl/vcvYc
http://bit.ly/2fLsr4u -> https://goo.gl/vcvYc#bam
http://bit.ly/2gdX68P -> https://goo.gl/yVlLVD
http://bit.ly/2gdX6G8 -> https://goo.gl/yVlLVD#bar

Finally, open the above links in browser, but with/without appending yet another fragment:
http://bit.ly/2fyCh6F -> https://www.youtube.com/
http://bit.ly/2fyCh6F#baz -> https://www.youtube.com/#baz
http://bit.ly/2fLsr4u -> https://www.youtube.com/#bam
http://bit.ly/2fLsr4u#baz -> https://www.youtube.com/#bam
http://bit.ly/2gdX68P -> https://www.youtube.com/#foo
http://bit.ly/2gdX68P#baz -> https://www.youtube.com/#foo
http://bit.ly/2gdX6G8 -> https://www.youtube.com/#foo
http://bit.ly/2gdX6G8#baz -> https://www.youtube.com/#foo

(It's a bit hard to follow, but notice the final landing page always has the last fragment within a redirection chain.)

Thanks!

[DKMudrechenko]

Hello, any updates on this issue? I still experience it on both iOS and andorid

[DKMudrechenko]

Hi, it has been a while since I initially posted the issue, however I still experience the problem when using Google PWS on Android (haven't tested on iOS this time, but I suspect it will also fail). Maybe someone could point out to me a spot in the source code where PWS handles fragments?

[gfwilliams]

I believe I'm facing this issue too.

I'm using Puck.js to measure the amount of times a door has been opened and to then report that as an Eddystone URL. The following URL gets transmitted, which I can verify using nRF Connect: https://goo.gl/D8sjLK#12

This redirects to https://www.espruino.com/dooropen.html#12 if you open it in a browser, but when viewed via the Physical Web link the bit after the # has been stripped off.

It's a shame as this would be a great way to transfer small amounts of information without an app.

[beaufortfrancois]

@mmocny Can you have a look at this?

[gfwilliams]

If you have a Puck.js or an nRF5xDK with Espruino, it should be as simple as uploading:

require("ble_eddystone").advertise("goo.gl/D8sjLK#12");

[gfwilliams]

Is there any news on this? I'm just about to send a book to the publishers where I'm trying to push data in a URL, and I was kind of hoping this might be fixed by now.