Re: [whatwg] HTTP status code from JavaScript

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