You might want to review .

In particular:


On Mon, May 26, 2014 at 10:02 AM, Michael Heuberger
<> 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 ................
> Website ..............

Reply via email to