Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

301 redirects: a dangerous one way street (2012)

jacquesmattheij.com

Post reply on HN
Print view View original

41–50 of 92 posts

Re: 301 redirects: a dangerous one way street (2012)

#41

Post by filleokus »

arbitrage wrote: post #33
nly wrote: post #28

Earlier quoted context omitted.

This isn't just a problem with things like HTTP. The industry as a whole lacks a standard uniform way of dealing with domain transfers or expiration. CAs for example will happily issue certificates that expire after your domain.

It's not the CA's job to make sure your domain isn't expiring. It's yours.

I mean, would it not be a problem for the CA that you (after the domain has expired) still is in possession of a valid certificate for a domain which you do not have control over?

Re: 301 redirects: a dangerous one way street (2012)

#42

Post by maaaats »

_Codemonkeyism wrote: post #3

The problem with 301 without cache headers is that some browsers cache this forever due to some interpretation what 'permanent' means. You often can't use 302 because all your external links no longer work SEO magic for you with a 302. Google only transfers link juice with 301 [1]. If you make a mistake and misconfigure your server, you're toast. If a disgruntled employee 301 redirects your domain, you're toast. If a…

> If a hacker (from a competitor) 301 redirects your domain, you're toast.

Reminds me of the guy that "got hold" of Google's domain for a few minutes. What if something similar happened and someone were able to make this redirect? Millions would be affected.

Re: 301 redirects: a dangerous one way street (2012)

#44

Post by hueving »

arbitrage wrote: post #33
nly wrote: post #28

Earlier quoted context omitted.

This isn't just a problem with things like HTTP. The industry as a whole lacks a standard uniform way of dealing with domain transfers or expiration. CAs for example will happily issue certificates that expire after your domain.

It's not the CA's job to make sure your domain isn't expiring. It's yours.

It sort of is. A CA shouldn't issue a certificate for a domain that may be released and repurchased before the cert expires.

Re: 301 redirects: a dangerous one way street (2012)

#45

Post by wtbob »

arbitrage wrote: post #33
nly wrote: post #28

Earlier quoted context omitted.

This isn't just a problem with things like HTTP. The industry as a whole lacks a standard uniform way of dealing with domain transfers or expiration. CAs for example will happily issue certificates that expire after your domain.

It's not the CA's job to make sure your domain isn't expiring. It's yours.

> It's not the CA's job to make sure your domain isn't expiring. It's yours.

Really? In the simplest case, their entire job is certifying that the holder of the private key is the holder of the domain name[1]. That begs the question, of course: how is it that we trust every single CA to certify every single domain? Why don't we trust the issuer of each domain hierarchy to certify only those domains it's permitted to issue?

The entire XPKI is broken, broken, _broken_.

[1] In the more complex case, of course, they certify that the keyholder is some external entity.

Re: 301 redirects: a dangerous one way street (2012)

#46

Post by draw_down »

arbitrage wrote: post #33
nly wrote: post #28

Earlier quoted context omitted.

This isn't just a problem with things like HTTP. The industry as a whole lacks a standard uniform way of dealing with domain transfers or expiration. CAs for example will happily issue certificates that expire after your domain.

It's not the CA's job to make sure your domain isn't expiring. It's yours.

Come on. It's the CA's job to accurately tell you who you're communicating with.

Re: 301 redirects: a dangerous one way street (2012)

#47

Post by jrumbut »

manyxcxi wrote: post #27
Typhon wrote: post #14

Earlier quoted context omitted.

This seems yet another example of web professionals not understanding HTTP. Much like webpages that say "404 not found" with a "200 OK" header.

In their defense that is probably the case of their MVC framework or CMS returning a 200 after not being able to match the route and not really them doing it on purpose. But yeah, I agree- (though I've missed them I'm sure) I pretty voraciously make sure my HTTP status matches my intended response- and sometimes that means you've got to write the code in the controller that tells the request to specifically return a…

I would say this falls under web professionals not understanding their framework, which is at least as common a problem as not understanding HTTP.

Re: 301 redirects: a dangerous one way street (2012)

#48

Post by [deleted] »

_Codemonkeyism wrote: post #3

The problem with 301 without cache headers is that some browsers cache this forever due to some interpretation what 'permanent' means. You often can't use 302 because all your external links no longer work SEO magic for you with a 302. Google only transfers link juice with 301 [1]. If you make a mistake and misconfigure your server, you're toast. If a disgruntled employee 301 redirects your domain, you're toast. If a…

[deleted]

Re: 301 redirects: a dangerous one way street (2012)

#49

Post by rebelde »

franze wrote: post #19

2012 - somebody should write 2012 into the title of this post (that by the way hasn't any concrete data) I did some testing in 2009, think around 2012 and 2014. Additional to loffilegrepping after some big site URL rewrites. It's a non issue. No caching headers, the redirect gets cached only for the current browser session. Close it, reopen it, gone, done. Lets discuss this one based on data. (Which I cant provide ri…

It still seems to be a problem.

I just tested it in Firefox on a Mac. I restarted Firefox. I even rebooted. Developer Tools > Network tab says "cached". I can't confirm that it is cached forever, but it is not only "for the current browser session".

Re: 301 redirects: a dangerous one way street (2012)

#50

Post by zrm »

_Codemonkeyism wrote: post #3

The problem with 301 without cache headers is that some browsers cache this forever due to some interpretation what 'permanent' means. You often can't use 302 because all your external links no longer work SEO magic for you with a 302. Google only transfers link juice with 301 [1]. If you make a mistake and misconfigure your server, you're toast. If a disgruntled employee 301 redirects your domain, you're toast. If a…

Not only that, anybody with a WiFi Pineapple or any other MITM could 301 redirect anything you visit without HTTPS to their spam site.

It seems like browsers interpreting permanent as forever is some kind of a bug. Even if that's literally what it says, that's not what anybody wants. What great evil is being prevented by not having it expire and be refreshed after 45 days?

Post reply on HN