Re: [whatwg] HTTP status code from JavaScript

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