search

esgibter / fandomstats

Fandom Statistics
12 stars 2 forks source link

Don't show Hover when someone uses wrong url #37

Closed annathecrow closed 8 years ago

annathecrow commented 9 years ago

I've been flailing around, trying to remember the right url for the api, and I kept getting this. Definitely not supposed to happen. What the hell is that thing anyway? I do think Flask returns 404 as it should, but the visitor gets Hover.

annathecrow commented 9 years ago

okay, this keeps happening. Today I've got Hover twice, and when I tried them later, I got the proper JSON result. I don't know what's happening here, and google isn't helping. Is this a Flask bug? Is something wrong with our app engine setup?

esgibter commented 9 years ago

Huh weird. Can you add more examples here? E.g. add the URL you see the hover page vs the json page.

I think there's definitely an issue with the malformed url returning a hover page instead of being caught with a flask http error.

destinationtoast commented 9 years ago

I've had this happen lately, too -- will try to record examples, but they're well-formed URLs that sometimes yield Hover instead of results!

On Sat, Feb 14, 2015 at 11:09 AM, esgibter notifications@github.com wrote:

Huh weird. Can you add more examples here? E.g. add the URL you see the hover page vs the json page.

I think there's definitely an issue with the malformed url returning a hover page instead of being caught with a flask http error.

— Reply to this email directly or view it on GitHub https://github.com/esgibter/fandomstats/issues/37#issuecomment-74387828.

esgibter commented 9 years ago

Hm I could add logging as the first step. Might be a google apps engine thing.

esgibter commented 9 years ago

Ok I deployed a first fix for two potential error cases. if you keep seeing this let me know how you reproduced!

destinationtoast commented 9 years ago

I got the hover error again, this time for the following URLs: http://fandomstats.com http://fandomstats.com/index.html http://fandomstats.com/api/v1.0/stats?tag_id=F/F

Edit: note that I possibly just broke this myself somehow; I just made my first commit to the project (added bookmarks.html to the same directory as index.html). I don't think that should have killed the site, but maybe it did.

Edit 2: okay, it just started working again, and I didn't change anything. Seems to be an intermittent Hover issue?

annathecrow commented 9 years ago

today I got a Hover on this url: http://fandomstats.com/api/v1.0/stats?tag_id=F/F&tag_id=Carmilla It it the same Hover as usual? It feels a little different, but I don't have any old screenshots. 2015-06-20_170733

EDIT: The URI might be wrong. I wasn't able to find any specs for the API in the GDrive (that's what I get for not touching the project for half a year)

annathecrow commented 8 years ago

Today I got a Hover on http://fandomstats.com. I had to reload several times before I got to the page. :(

According to the App Engine logs:

This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application.

Is it possible that Hover does some automatic check on the IP? I can't find anything about it. We need to either disable that (if it's happening) or get App Engine to keep the process running. Otherwise people are going to get Hover pages. :[

EDIT: Apparently the process start wasn't the cause, because it just happened again. :[ I tried to snoop on the DNS records (dig and DNSInspect and curl -I and other things), but the only strange thing I can see is that the A record the DNS is returning is four Google IPs... and one of Hover. Could there be a conflict?

EDIT2: ...what. When I fetch fandomstats.com in console (curl or dig), it... rotates through the DNS records. So on 4 of 5 requests I get the app, and on the fifth I get Hover. This doesn't happen in Firefox, but that's because it uses its own DNS cache. I'd say that the irregular appearance of the Hover page is the result of Firefox occasionally "hitting the jackpot" of the fifth cycle. ...this sounds so bonkers I kind of hope it's just me misunderstanding my tools.

annathecrow commented 8 years ago

Fixed.

We forgot to remove the default A-records that Hover has in the DNS settings. There are two ("@" and "*"), both pointing at "64.98.145.30" - the problematic Hover server from my last comment.

I can't believe I didn't notice this sooner.