Live data from Hacker News

301 redirects: a dangerous one way street (2012)

jacquesmattheij.com

81–90 of 92 posts

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

#81
post #80

Is there any company that provides 301 or 302 as a service? -- something cheap. I know it's not hard to set-up a small box on AWS and install Node.js (or whatever). But I would pay few dollars a month for some service to run that for me.

Wouldn't a URL shortener service be good enough? (E.g. https://goo.gl/ )

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

#82
post #80

Is there any company that provides 301 or 302 as a service? -- something cheap. I know it's not hard to set-up a small box on AWS and install Node.js (or whatever). But I would pay few dollars a month for some service to run that for me.

Wouldn't a URL shortener service be good enough? (E.g. https://goo.gl/ )

Oh I re-read the article. You mean in the case of old domains.

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

#83
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.

Is the status line technically a header?

No.

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

#85

Earlier quoted context omitted.

Wouldn't a URL shortener service be good enough? (E.g. https://goo.gl/ )

Oh I re-read the article. You mean in the case of old domains.

Yes, in the case where you have a old domains and you want Google page rank juice (via 301).

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

#87
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.

Stupid protocol decisions are still stupid protocol decisions no matter how much you condescendingly try and blame the user.

What's stupid about differentiating between errors and success?

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

#88
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…

Here's the relevant Gecko (Firefox) code which tries to use the max-age and expires headers first and then will set it to forever if the response code was 300, 410, 301, or 308. Note that I'm going by a somewhat shallow code reading after a recent investigation. There's a lot of stuff going on in gecko/necko that could potentially apply some failsafe time limit, maybe in the cache implementation, so I wouldn't take this as 100% for sure. Breaking on this function with gdb and tracing the flow is probably a better idea if you really want to know.

https://dxr.mozilla.org/mozilla-central/source/netwerk/proto...

The 301, 308 stuff comes from IsPermanentRedirect which is here: https://dxr.mozilla.org/mozilla-central/source/netwerk/proto...

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

#90
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.

Is the status line technically a header?

Request (section 5) and Response (section 6) messages use the generic message format of RFC 822 [9] for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body.

/quote RFC2616 (So, the status line is an entity of its own, which is followed by headers.)

Post reply on HN