I just learned about HTML redirects (2020) | Hacker News Reader

I just learned about HTML redirects (2020)

apitman.com

110 pointssc9081 comments

I remember once learning that php has a `header` function and have been using 'location:...' since ever (pre-2000) as php was almost always supported by hosters like dreamhost, hostgator, and nearly every Linux install came pre-installed with Apache and the php mod. The meta htttp-equiv was a last resort (like gh-pages). Never really used the JS option unless it was part of the application.

This is also used as a poor man’s live feed: just use this element to reload the page or frame on a set interval.

This is one of the oldest tricks in the book and was used heavily before WebSockets and similar became mainstream.

Monit does to this produce a live feed. It’s kind of annoying sometimes, you lose highlighted text.

I fondly remember html-only iframe chats.

IIRC CGI:IRC had an even more clever version of this: still no JavaScript needed, but Also no refresh needed, as the chat frame response would simply be held open and stream new messages. I never dug too deep into it, but it seemed to work surprisingly well.

Ha remember that too! It’s basically just keeping the socket open and continuously streaming a response. As if it’s just a slow download. It’d also send heartbeat null values to keep the connection open. Of course in the CGI days that really didn’t scale well as it required a whole process to run for each user.

it scaled as well as you would expect coming from those days.

the alternative was a whole computer plus modem per user.

This is called Server Sent Events, SSE for short.

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...

SSE is cool, but as others have pointed out, this isn't that. I also wouldn't call this Comet: almost unilaterally, Comet referred to using it in concert with JS/Ajax and usually was just a fancy way of saying long-polling (though I admit it's a bit broader than that in truth). What CGI:IRC did was different: it streamed HTML directly. More to the point, it didn't use chunked encoding or any kind of framing in the body. It just kept the connection open and kept sending HTML in realtime. I don't think this ever had a term associated with it, or at least I was never aware of one.

Looks like 'Comet' got coined in 2006. The CGI:IRC approach.. I had a smile and an "aha" on seeing the term "forever frames" :-)

I think the wiki page is wrong that it involved chunked encoding

Woah! I completely and entirely forgot the term "forever frame" existed.

Another term you don't see too often these days is the "holy grail" layout. I definitely remember the days of messing with negative margins and clearfix to get my page layouts to look nice while still working in IE 6 :)

Me too :-D

I think you're right that Comet refers more to the JavaScript techniques that came from those "forever frames".. but to me it was all about the streaming HTTP hack at the heart of it.

I guess it's academic now :-)

Regarding holy grail layout and IE6.. so you're telling me you're a masochist!

SSE came along much later. At the time it was common-ish to just slowly send HTML tags. I think at some point there was a gorgeous hack where they dynamically rendered and sent GIF frames with the messages of the chatroom.

The broader technique became known as Comet: https://en.wikipedia.org/wiki/Comet_(programming)

CGI:IRC used an early frame approach, no JS required.

At some point JSONP became popular, even for 3rd party APIs.

  <script src="http://dont-xss-me/please?format=jsonp&callback=lol">

Server writes:

  lol({ ... })

  lol({ ... })

That’s the modern variation. The original didn’t have any framing like they.

controversial opinion, frames were awesome...for some things

I got PTSD... then again, a lot of things were wrong about that system. GET requests casually loading up whole database in memory while calling stored procedures that inexplicably modify like half of persisted version of it. and that's just to render some stupid list o_0

agreed, I help make Chemistry World with a chemist that had a cool 3d .mol viewer with frames back in the day when 3d was pretty fancy :)

And webcams. I still see these occasionally and wonder if something is broken before realizing it's old-school.

Long polling HTML was popular for a while in the early aughts. Just never close the HTTP connection and stream new HTML elements onto the page. I don’t think that would get along with modern tooling.

Also not widely known: the multipart/x-mixed-replace media type, allowing you to send multiple files and have them replace each other. A simple streaming solution without video, WebSocket, or JavaScript, just an <img>.

This was so annoying when you wanted to copy some text and the page kept refreshing at the wrong time

Drudge Report site still does this, I think. Maybe it's JS now, never checked.

Oh my. Chat.cgi days! :D

Ah, and next you might discover one of my favorite unresolved browser issues:

https://bugs.chromium.org/p/chromium/issues/detail?id=63107

My fav was Marquee. Could put one inside the other, make one vertical, add some text and watch it bounce around like the DVD screensaver logo.

Now do <blink> :)

I remember these from when I initially taught myself HTML (4) and CSS as a kid.

It's kind of amazing how parts of the spec that seem dated or obsolete can still be useful today and are even widely used in corner cases.

It would be nice to see a collection of "dated" or "usually forgotten" web tools like this, and how they can still be useful.

Yeah, I use it to direct new newsletter signups to a special url which redirects a user to my latest post. https://www.lloydatkinson.net/posts/2022/static-site-redirec...

Combining it with the referrer tag and you can make some pretty interesting graphs. With frames you can even do Floyd's algorithm.

I made a demo of this about 20 years ago but I think it just confused people. One of my early flops that I thought was cool. It was all in perl and I think there was some JS in there as well but I don't remember anymore. No idea where it is now.

Rewrite it and make a hyped up pitch page. People will call you a genius and I'll pretend not to care

I was so sure archive.is/wip/xxxxxx used this but I just checked and it uses

now

for example, I tried out view-source:https://archive.fo/wip/RpDSg

does anyone else remember seeing meta refresh? if so, any idea why they switched to javascript reload

Ahh. This brings back memories. I used to do this when I was using Adobe (Macromedia originally) FLASH back in the day. If no FLASH, show them the shitty version. HAHA. Good times.

You'd be surprised how often Flash was "the shitty version" as it was almost always bloated with long load times, inaccessible content and a lot of pointless stuff that was clearly to impress the client who comissioned it, not the poor user who wanted to find something out.

O no doubt.

Sometimes im flabbergasted on how the most basic html knowledge is lost on newer generations.

This is what you get if you learn everything by just googling exactly what you need for the moment. Reading proper books and RFCs are underrated these days.

Most people learned about this stuff by searching the web back in the day, instead of "reading proper books and RFCs." The reason this knowledge is lost is entirely due to modern web dev taking place within frameworks that abstract all that lower-level knowledge away.

I regularly ask people: have you read the man page? Seems a minimum effort one can do.

The man page for git has 1085 lines on my system. That's just too long with too much irrelevant information to be reasonable to expect someone to read when they just want one thing. I've never used them in all my time in the industry.

ChatGPT is a life saver for me though. I looked all over to try to find how to just see the history of a branch and got a million wrong results, but ChatGPT on GPT4 told me right away it was git log --first-parent <branch_name>.

Maybe because we collectively pretty badly handled knowledge transmission between generations.

For the pioneers the most difficult part of learning CS was to get hardware needed. This mostly determined the technological stack they would then learn.

Nowadays hardware is commodity and the main problem is to determine what the hell you should start learning first because you can't learn everything it has now became humanely impossible.

I was born somewhen in the middle. Because of my first field I wish I could have mastered python. But at that time the python2/3 war was at the highest and you couldn't find reliable documentation. Hell even python3 tutorial kept on blabbering about how python2 concept translated. What was i supposed to do? learn both?

That is why I focused on SQL because at least documentation was quite stable (special thanks to PostgreSQL documentation teams).

I can only imaging the nightmare that must endure rookies frontend dev nowadays.

Ok, I'll bite - how else do people do this? (Speaking as someone who has ONLY ever done it this way.)

The most common is using an HTTP header. Less common: `document.location` in JavaScript

https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirectio...

That wouldn't work in a noscript

Not sure why you're being downvoted. Many of the sibling comments are referring to server side generated HTTP 302 headers, and server side (without lots of fancy shenanigans) you won't know (server side) if the client has disabled scripting on the first page hit.

And document.location is pointless if the client has turned off scripting.

Different readings of the initial question:

A) “how do people redirect”, to which the point about noscript sounds like irrelevant whining

B) “how do people redirect only visitors who don’t have scripting” to which most of the answers are trivially wrong

Therefore the method called "progressive enhancement" might be an option to start with an HTML-only variant and load JS only if available and required for the current page.

The noscript tag is the correct way to do this. Server side, when you first generate page content you have no idea if the client has scripting enabled, which is why you include a noscript element to advise the user what to do, or redirect them using a meta tag inside the noscript element.

So all these suggestions below to use server side generated HTTP headers and 302 (or 301) redirects are incorrect...because you won't know, on the first page hit, if the client has scripting enabled. At this point in time only the client knows if scripting is available. Also browser capability sniffing based on headers sent from the client in the first request is not reliable.

For more info see:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/no...

> So all these suggestions below to use server side generated HTTP headers and 302 (or 301) redirects are incorrect...because you won't know, on the first page hit, if the client has scripting enabled.

Perhaps I’m misunderstanding you, but do you think that the HTTP approach only works when JavaScript is enabled? That isn’t the case.

Go ahead and use HTTP 3xx responses; they work in all cases. Don’t use the <meta> element or the <noscript> element. Just redirect with HTTP. If you try to use HTML for this, you’ll be serving up 200 OK responses and things that understand HTTP but not HTML won’t understand there’s a redirect.

Ok, in the context of the article, what I'm saying is when a browser requests a page for the very first time, the server will have no idea if scripting is enabled and so your server side code will have no idea whether to send a 302 redirect to your no-script content.

This is why the noscript tag exists and should be used.

Yes I'm aware there are various sniffing techniques you could use to work out if scripting is enabled but these are not always reliable. Only the browser knows authoritatively if scripting is available and hence you should use the noscript element to respond to clients that disabled scripting.

Oh I see what you mean now. You don’t think that determining scripting capability is necessary for the redirect, you only care about it because it’s the purpose for the redirect in this case.

In that case I would completely reposition the argument: you shouldn’t do this at all, so it doesn’t matter how you redirect. It’s basically never the right move to try to sort your users into JavaScript and non-JavaScript and have two different pages for each.

If you want to handle this situation reliably, you need to build the page so that it works without JavaScript and then have the JavaScript that ends up executing progressively enhance the page.

HTTP 3xx status code with a Location header.

Most of the time it’s via a server redirect or a rule on the load balancer.

Ok, how does the server or the load balancer know if scripting is enabled on the first request?

The 30x redirect status codes are handle by the browser whether or not scripting is enabled. It is part of the http standard.

https://www.rfc-editor.org/rfc/rfc9110#status.301

I know this, please read my comment here:

https://news.ycombinator.com/item?id=35675861

one way it's not done is with DNS

Well...

Serve a "shitty" page by default, redirect with JS to "enriched" page. Or tinker with server configuration to depend on 'Host: nojs.plz.fqdn'.

I've recently deployed this trick on my company's confluence instance (with an HTML macro) to create a "poor man's" link shortener that allows me to change the link target after the fact.

Also recently deployed it as a very simple server side denounce: when the client first accesses page X a long running operation is dispatched. Subsequent requests for the same resource before it's done processing return a plain HTML response that says "Still thinking about it" and meta refresh after 1 second.

This reminds me of the days of making text adventures that used a width 0 frame to store background variables.

I use

see:

view-source:https://angularten.github.io/

I remember when it was released as a new feature (~1995).

Amazing that these were forgotten!

Hehe, the good old html meta redirect. As a kid in the early days of the web I loved to post redirects to porn websites in guestbooks to check if the website was sanitizing the user content properly. Worked way to often :D

This reminds me that while I’ve been programming for a paycheck since 1998 my knowledge growth in html stopped at about 2001. Are there any good courses or recommendations for seasoned pros who never stopped to learn HTML5?

> The term HTML5 is essentially a buzzword that refers to a set of modern web technologies. This includes the HTML Living Standard, along with JavaScript APIs to enhance storage, multimedia, and hardware access.

> You may sometimes hear about "new HTML5 elements", or find HTML5 described as a new version of HTML. HTML5 was the successor to previous HTML versions and introduced new elements and capabilities to the language on top of the previous version, HTML 4.01, as well as improving or removing some existing functionality. However, as a Living Standard HTML now has no version.

Even though it may cover a lot of basic and familiar topics, I think the following is the best (re)introduction to HTML:

HTML: HyperText Markup Language - https://developer.mozilla.org/en-US/docs/Web/HTML

> The term HTML5 is essentially a buzzword

HTML5 is just the common name of the living standard. It's clear, unambiguous, and what everybody uses. It is not a "buzzword".

I tracked down the Git history where the phrase "essentially a buzzword" was introduced in this pull request:

https://github.com/mdn/content/pull/5116/files#diff-7cfca62e...

I agree that it's unnecessarily dismissive.

Web development has trained me to Google (now often ChatGPT) everything even if I already know how to do it because it changes so much haha

It makes me look stupid in code interviews because I commit very little to memory but professionally it's helped me catch a lot of syntactical upgrades.

I use this trick to autorefresh the resource that I'm working on.

Putting 0 value used to be a bad idea, as it was a signal to the browser and various ad blockers and anti viruses that it was a rogue redirect. Wonder if it’s different these days?

when they just learned about it was in 2020.

Goddammit!

Noob learns basic HTML tag. The post.

Reply on news.ycombinator.com