Tweaks to ipwb Service Worker support, fallbacks, and compatibility #146
Comments
machawk1
changed the title
|
Going forward, provisioning HTTPS wont be an issue or after for webmasters because web giants are pushing hard on it. HTTPS would soon become as ubiquitous as JavaScript. Remember those days when it was almost necessary to provide a non-JS fallback for every website for human users, now it is only needed for robots/crawlers (which wont be the case for too long and crawlers catch up). |
|
I am concerned with users that want to test this out then share their experience to others through an endpoint with an IP address as the host, e.g., I can view replay at http://localhost but it breaks when I share http://21.44.57.29. I don't know the state of SSL for an IP but a "compatibility mode" would be useful for the above scenario (and others we are not considering) that would allow ipwb to work on http for the time being. UPDATE: There's a discussion of requesting certificates for an IP on the Let's Encrypt forum. I do wonder that if a hostname is relatively static, e.g., my IP maps to |
|
HTTPS is allowed on public IP addresses, but not on private ones (may be self-signed certificates are an exception). However, Let's Encrypt, a popular free CA does not issue certificates on bare IP addresses of any sort. One can possibly use services like http://xip.io/ to bypass that limitation though. |
|
@ibnesayeed Or the ^above update. Ideally, we would make this as automated as possible. Any clue as to whether xip.io has an API? |
|
You dont really need an API for http://xip.io/, you just prefix it with your IP address as illustrated on the page. It is nothing but a wildcard DNS provider that reads the IP encoded in the hostname itself. |
|
@ibnesayeed Do you believe requesting a certificate from LE using xip.io and installing said certificate in the local ipwb web (flask) endpoint would work? I have never programmatically interacted w/ the LE API so am unsure of the dynamics. https://pypi.python.org/pypi/letsencrypt |
|
Yes, it should work. Let's Encrypt requires the machine to exposes port 80 for verification process, but there might be alternative ways to do so. One thing to note though that LE certificates have a short expiry time (90 days), that means new certificates would be required after a while and the Flask instance would require a reload. An alternate approach would be to perform TLS termination using a reverse proxy that has certificate management automation in place. https://caddyserver.com/ could be a good example of that. |
|
Also, e.g., curl. What sort of more gracefully degradation to prevent zombies would be to make an attempt at rewriting when the serviceWorker cannot be used for rerouting. |
|
I deployed ipwb on one machine after setting the Flask IP to 0.0.0.0 instead of localhost. ipwb index ipwb/samples/warcs/froggie.warc.gz | ipwb replayOn accessing the replay system on the original machine from a second machine on the same LAN then accessing a memento, the page causes an infinite repeated loop trying to access the main HTML page. Output: machawk1@gigabox:~/ipwb$ ipwb index ipwb/samples/warcs/froggie.warc.gz | ipwb replay Executing first-run procedure on provided sample data. * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit) looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:01] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:01] "GET /webui/webui.js HTTP/1.1" 200 - looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:01] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:01] "GET /webui/webui.js HTTP/1.1" 200 - looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:01] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:01] "GET /webui/webui.js HTTP/1.1" 200 - looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:01] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:01] "GET /webui/webui.js HTTP/1.1" 200 - looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:02] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:02] "GET /webui/webui.js HTTP/1.1" 200 - looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:02] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:02] "GET /webui/webui.js HTTP/1.1" 200 - looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:02] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:02] "GET /webui/webui.js HTTP/1.1" 200 - looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:02] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:02] "GET /webui/webui.js HTTP/1.1" 200 - looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:02] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:02] "GET /webui/webui.js HTTP/1.1" 200 - looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:02] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:03] "GET /webui/webui.js HTTP/1.1" 200 - looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:03] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:03] "GET /webui/webui.js HTTP/1.1" 200 - looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:03] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:03] "GET /webui/webui.js HTTP/1.1" 200 - looking for edu,odu,cs)/~mkelly/semester/2017_spring/remotefroggie.html 20170301192639 in /tmp/723880.cdxj 192.168.1.10 - - [01/Jul/2017 21:56:03] "GET /20170301192639/cs.odu.edu/~mkelly/semester/2017_spring/remotefroggie.html HTTP/1.1" 200 - 192.168.1.10 - - [01/Jul/2017 21:56:03] "GET /webui/webui.js HTTP/1.1" 200 - ^\Quit (core dumped) machawk1@gigabox:~/ipwb$ |
The ipwb replay system uses service workers for URI-M rewriting. Some browsers don't yet support service worker. At the very least, we should provide a message in the UI when SW registration fails.
A further approach would be to have URI-writing as a fallback, which is really messy and problematic.
As an additional use case, service workers currently require either HTTPS or localhost. We have been testing on localhost but if someone wanted to deploy this a different host sans HTTPS, SW would not work.
We could say that we only support browsers that support SW and only SWs on HTTPS -- excluding these other scenarios would make testing easier -- but also means ipwb breaks for some users.
We can snub it or mitigate it.
The text was updated successfully, but these errors were encountered: