Http should send Javascript On and the Version in Gets, Posts, Etc

Hi All,

I have encountered a issue with web design that appears to be part of the http specification. I believe that the version of ECMA (Javascript) and if it is on or off should be included with the http request header when sent to a server. It might fit well into this RFC;

https://www.ietf.org/id/draft-ietf-httpbis-client-hints-02.txt

Perhaps a new section between 7 & 8 as follows;

8. The ECMA script (Javascript) Client Hint

The “ECMA” request header field is a number or text that indicates the client’s current ECMA implementation version. A blank ECMA hint would indicate that ECMA script is currently turned off.

 ECMA = Text [32 ASCII characters]

If ECMA occurs in a message more than once, the last value should be used to override other occurrences. Examples;

 #1 ECMA script is turned off
 ECMA:

 #2 ECMA script is on the Next version
 ECMA: Next

 #3 ECMA script is on version 5.1
 ECMA: 5.1

The basic thing that I am trying to do is determine if Javascript can be used to assemble a html page or if it should be done server side if Javascript is turned off. Currently I can do this by assuming javascript is on and then redirecting from the browser when it is off using something like;

When javascript is on I can assemble (and cache most of the repeated parts of the page). i.e. profile these pages in Chrome and check the speed and cacheing; http://mokshayoga.com/tt/tuition.html then http://mokshayoga.com/tt/index.html

Vs. https://www.mokshayoga.com/chicago-yoga-policies.html then https://www.mokshayoga.com/chicago-yoga-events.html

Cheers,

Scott Morgan

Nit: “ECMA” is a bad name, because ECMA does much more than Javascript. If you want ECMAscript, say ECMAscript.

I’m skeptical, though - Is there anything that makes life easier than

<a href=“nonjs-url” onclick=“navigateTo(js-url)”>

would give you, in return for the increased fingerprint and passive-monitoring capabilities that it offers?

A way to solve the exact proposed problem without anything additional added is to always be prepared to render things server-side. Using javascript when you send requests add the accepts (iirc) request header and set it to whatever you expect back application/json or partial-html if you only want to return a part of a view to inject into the current page. Then on the server you just see whether the client is expecting some specific form of response and do that, defaulting to returning a redirect or a full page response as-needed.

I don’t see the case for needing another header here. The proposed problem is perfectly solvable with everything we have available right now.