View Issue Details

IDProjectCategoryView StatusLast Update
0003215HTML & PERLBug Report - Interfacepublic2018-07-11 03:18
ReporterCDB-Man Assigned ToCDB-Man  
Status closedResolutionno change required 
Summary0003215: ResourceTB: AnimeNFO links cannot be updated if the change in URL is other than the AnimeNFO ID
DescriptionRefer to:

For this entry:

Old link:,1309,pkivzb,a.html
New link:,1309,pkivzb,pretty_cure.html

>> ERROR: no changes were made

Presumably, since the AnimeNFO ID did not change as we only store the AnimeNFO ID, the system considered it as no change?

The old link will work if you have already visited the page once before during the same session, but otherwise it points to 404 not found upon first visit with no cache.
TagsNo tags attached.


child of 0003220 resolvedDerIdiot Resources: change some more resources to HTTPS 



2018-07-01 20:51

manager   ~0004248

[2018.07.01 15:44:03] <Dagger> it just has a completely broken http:// -> https:// redirect, and all our links to it are generated using http://
[2018.07.01 15:44:23] <Dagger> HTTP request sent, awaiting response... 301 Moved Permanently Location:,1309,pkivzb,pretty_cure.html/ [following]
[2018.07.01 15:44:26] <Dagger> that trailing / should not be there
[2018.07.01 16:09:43] <CDB-Man> also note our links end with "a"
[2018.07.01 16:09:55] <CDB-Man> but the current URLLs are named, ie "pretty_cure"
[2018.07.01 16:31:02] <Dagger> it seems to correctly redirect for that part, if you manually strip the / from the https:// redirect
[2018.07.01 16:34:22] <Dagger> also it sets strict transport security on non-error pages, so people who have visited the site recently won't hit the redirect (because their browser will do it for them)
[2018.07.01 16:34:49] <Dagger> so close. if they set it on 404s too then it'd only be an issue on the first load


2018-07-07 19:37

manager   ~0004249

The issue is on AnimeNfo's side with their broken HTTPS redirect.


2018-07-07 22:42

manager   ~0004250

[2018.07.07 18:12:38] <Soulweaver> "unless you've already been to the site/page in the current browser session" is the key part. I tested right now and got the wrong redirect multiple times, then I visited, then tried the same link again and it worked properly every time after that
[2018.07.07 18:12:52] <Soulweaver> some really funny business going on their side
[2018.07.07 18:13:25] <Soulweaver> but even if it happens rarely, is there really any downside to linking to https directly instead
[2018.07.07 18:30:30] <Dagger> they use HSTS, but they only send the HSTS header on 200 responses, not 404 responses
[2018.07.07 18:30:55] <Dagger> the bad http:// -> https:// redirect leads you to a 404 page, so no HSTS is set, so your next request will still be http://
[2018.07.07 18:31:03] <Soulweaver> mm that might be it
[2018.07.07 18:32:17] <Dagger> we can work around this easily by just linking to https://, and we probably should do that anyway because the site redirects all http:// to https:// as it is
[2018.07.07 18:32:21] <Dagger> may as well save users the redirect
[2018.07.07 18:32:58] <Dagger> (although okay, after successfully loading a page on the site a single time they'll have HSTS set and so won't hit the redirect, but still)

Issue History

Date Modified Username Field Change
2018-07-01 18:57 CDB-Man New Issue
2018-07-01 19:00 CDB-Man Description Updated
2018-07-01 19:01 CDB-Man Description Updated
2018-07-01 19:03 CDB-Man Description Updated
2018-07-01 19:06 CDB-Man Description Updated
2018-07-01 20:51 CDB-Man Note Added: 0004248
2018-07-07 19:37 CDB-Man Assigned To => CDB-Man
2018-07-07 19:37 CDB-Man Status new => closed
2018-07-07 19:37 CDB-Man Resolution open => no change required
2018-07-07 19:37 CDB-Man Note Added: 0004249
2018-07-07 22:42 CDB-Man Note Added: 0004250
2018-07-11 03:18 CDB-Man Relationship added child of 0003220