Surfaces redirects from URI-Ms. Closes #451 #452
Conversation
Codecov Report
@@ Coverage Diff @@
## master #452 +/- ##
=========================================
- Coverage 23.55% 23.4% -0.15%
=========================================
Files 6 6
Lines 1125 1132 +7
Branches 169 171 +2
=========================================
Hits 265 265
- Misses 843 850 +7
Partials 17 17
Continue to review full report at Codecov.
|
| if status[0] == '3': | ||
| # Bad assumption that the URI-M will contain \d14 but works for now. | ||
| uriBeforeURIR = request.url[:re.search(r'/\d{14}/', request.url).end()] | ||
| newURIM = uriBeforeURIR + resp.headers['Location'] |
There was a problem hiding this comment.
This will probably fail in many cases. I think the simplistic assumption made here is that extracted uriBeforeURIR is going to be a directory URI and stored Location header will be a relative path. Both of these are unrealistic assumptions. I think you can simply return the Location header without any modification and let the SW deal with it. I am not sure how will it behave in case of a full URIs (probably it will be caught by the SW too).
There was a problem hiding this comment.
The location header prior to this is a URI-R. Without the prepending of the replay system, the redirect forwards the user to the live Web.
There was a problem hiding this comment.
uriBeforeURIR ends up being http://localhost:5000/memento/12345678901234/.
There was a problem hiding this comment.
I misunderstood the uriBeforeURIR earlier. However, Location header is not going to be a full URI all the time, it could very well be a relative or absolute path.
As documented, the regex to pull the part of the URI-M before the URI-R assumes a 14-digit string. This can be done more reliably but for now it fixes the issue of 3XXs not being replayed.