[teh_klev]

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

[JimDabell]

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

[teh_klev]

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.

[JimDabell]

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.

<noscript> is an ancient design assuming that JavaScript is a binary enabled/disabled state, however this simply is not reflective of the real world. The vast majority of cases in which JavaScript does not execute will happen in the context of somebody using a browser with JavaScript enabled, so <noscript> can’t help you. You can use the latest version of the most popular browser, with all the settings enabled, no firewall or filtering, using a perfect Internet connect, no extensions getting in the way, with bug-free JavaScript delivered flawlessly, and still not have the JavaScript execute. And of course, if any of those factors vary, that can also lead to the JavaScript not executing.

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.