Comments
-
Greg Hurrell
As I replied to the original comment:
This is caused by someone or something hitting the feed under the "rails" host (which is just an alias), and the feed then gets cached with all the URLs pointing at the rails subdomain instead of wincent.dev, ruining the feed for everybody.
I actually fixed this a long time ago by explicitly forcing it to always use wincent.dev as the host regardless of what host is used in the request, but it looks like something in Rails 3 has broken that. Oddly, the spec suite, which explicitly tests this, passes fine.
I'll investigate and try to re-fix the issue again, but in any case I think it's about time the old rails subdomain was decommissioned anyway.
Ok, so this is now effectively mitigated because I've set up a rewrite rule to permanently redirect any request. This means that it should be impossible to touch the Rails app at all without going through "wincent.dev" as the host, so cached feeds should no longer get polluted in this way.
I've blown away all cached feeds, so newly-requested feeds should be fine from here on. (Note that if you try to look at the feed in Safari you might still see the old version of the feed, as Safari, or perhaps PubSubAgent, does some caching of its own.)
Will leave this ticket open however as I'd still like to investigate the root cause.
-
Greg Hurrell
Status changed:
- From: new
- To: open
-
Greg Hurrell
Ok, on reviewing the code base and the commit logs I can see that the explicit checks were taken out and I decided to enforce this before crossing the application boundary (ie in nginx). The fact that it was enforced over HTTP but not HTTPS was a bug.
Will mark as closed.
-
Greg Hurrell
Status changed:
- From: open
- To: closed
Add a comment
Comments are now closed for this issue.