Re: [whatwg/fetch] Header to opt out of opaque redirect (#601)

Being able to expose status code, location, and various other headers will be great when redirects are handled manually in a fetch. The name of this redirect mode is confusing and misleading. However, if we can someone opt-out of the `opaqueredirect` then the name can be justified.

Our use case is related to web archiving. An important need in web archival replay systems is to avoid live-leakage ([we call them zombies](http://ws-dl.blogspot.com/2012/10/2012-10-10-zombies-in-archives.html)). When a web page is archived and replayed (for example in the Internet Archive's [Wayback Machine](https://archive.org/web/) or other web archives), it is very important that all the page requisites are served from the archive and not from the live web. However, depending on how the resource was referenced (i.e., absolute URL, absolute path, relative), it may resolve to an invalid location or the live web. To prevent it from happening, archival replay systems rewrite all the references before serving to the client. However, in some complex situations when resources references are generated using JavaScript, they might fail to fix them.

To prevent it from happening we created [Reconstructive](https://oduwsdl.github.io/Reconstructive/) which allows intercepting all requests in a Service Worker and rerouting them back to the archive if they are going elsewhere. The goal is to free the server from performing any rewrites and deliver the original archived content which can then be fixed by the SW to ensure proper replay. This generally works, but there are many cases where the archive has captured redirect responses originally from the live pages and replays them back with the original `Location` header as seen at the time of archiving. If the location is an absolute URI (potentially using the domain of the original site, not the archive) then not being able to rewrite it from the SW before handling it over to the browser throws it out of the scope of the SW. Current work around is to make sure such headers are rewritten on the server side, but we would like it to work without the server being smart.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/601#issuecomment-408586229