- From: Michael Heuberger <michael.heuberger@binarykitchen.com>
- Date: Mon, 26 May 2014 12:52:53 +1200
- To: whatwg@lists.whatwg.org
Thanks heaps! On 26/05/14 12:29, Silvia Pfeiffer wrote: > 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 >> -- 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:53:25 UTC