- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 26 May 2014 10:29:43 +1000
- To: Michael Heuberger <michael.heuberger@binarykitchen.com>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>
You might want to review http://wiki.whatwg.org/wiki/FAQ . In particular: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F HTH, Silvia. On Mon, May 26, 2014 at 10:02 AM, Michael Heuberger <michael.heuberger@binarykitchen.com> wrote: > Hi Jasper > > On 26/05/14 08:09, Jasper St. Pierre wrote: >> >>> >>>>> * It is a redundancy. The browser already knows the status code, just >>>>> not JavaScript. >>>> That argument can equally well be used the other way round: it's a >>>> redundancy to expose in JS something that be easily exposed by the >>>> server. >>> I understand your perspective but you cannot compare two entirely >>> different things. Don't forget that most modern web apps are 99% driven >>> by JavaScript. If the server returns a 404, JavaScript is still unable >>> to read the initial HTTP status code. Think about it :) >>> >> The web server sends you back a response. It first sends the response code, >> then the response headers, then the response body. >> >> If you can alter the response code from the server, why can't you alter the >> response body? > > I know that my dear :) > > Whatever we alter on the server, Javascript on the client-side is still > unable to read the HTTP status code. > > I already mentioned in earlier emails that altering the response body is > a redundancy. The information is already in the header. > >> >>>>> * Adding inline JS <script> slows down the page load. >>>> In that case, use a meta tag: >>>> >>>> <meta name=http-status content=404> >>>> >>>> Then in JS: >>>> >>>> var status = >>> parseInt(document.querySelector("meta[name=http-status]").getAttribute("content")); >>>> Should this pattern become pervasive, it might bathe sense to >>>> standardize it and expose it in JS. Frankly, though, it's the first >>>> time I hear of such a request. >>> That would work but is an overhead, a redundancy. Why add another meta >>> tag if the status code is already in the HTTP header?? >>> >>> Yes, it's interesting why nobody has suggested this before. There is >>> always a first time. Probably I am the first to ask for this feature >>> because I've been working heavily with SPA's and node.js in the recent >>> years. >>> >>> Really, it would be awesome if JavaScript could read the HTTP status code! >>> >> Yes, ideally the initial request to the server would be accessible to the >> script, including the response code, response headers, and so on >> (document.initialRequest returns an XMLHttpRequest-like object that's >> already completed?) > > I have never seen document.initialRequest before. > >> At the same time, in order to deploy to sites without this feature, you'd >> need to be able to modify the response body accordingly as well. I think it >> makes sense to simply do that too. >> >> What server are you using here? Does it have a way of configuring it to >> modify the response codes for certain requests, but not the response body? > > nginx + node.js with ExpressJS > > Michael > > -- > > Binary Kitchen > Michael Heuberger > 4c Dunbar Road > Mt Eden > Auckland 1024 > (New Zealand) > > Mobile (text only) ... +64 21 261 89 81 > Email ................ michael@binarykitchen.com > Website .............. http://www.binarykitchen.com >
Received on Monday, 26 May 2014 00:30:28 UTC