W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] HTTP status code from JavaScript

From: Michael Heuberger <michael.heuberger@binarykitchen.com>
Date: Mon, 26 May 2014 11:31:40 +1200
Message-ID: <53827D5C.4060602@binarykitchen.com>
To: Tobie Langel <tobie.langel@gmail.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
Hi Tobie

On 26/05/14 00:51, Tobie Langel wrote:
> On May 25, 2014, at 13:48, Michael Heuberger
> <michael.heuberger@binarykitchen.com> 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.
> That's data's made and far from the truth. :-)

Okay, I do not know the exact percentage but it is definitely a very
high number. All I wanted is to emphasize how important JavaScript is
these days. Getting more and more popular.

>
>> If the server returns a 404, JavaScript is still unable
>> to read the initial HTTP status code. Think about it :)
> How so? What prevents the server from adding a 404 status code in HTML markup?

I already explained this in a previous email. Should I repeat it here?
In short: it's a redundancy when the same information is already sent in
the HTTP 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??
> This would be an overhead for *your* application. But adding code
> that's very much specific to your use case to the whole platform
> creates overhead for browser vendors which have to implement and
> maintain that code.

Overhead? I am not so sure about that. I saw Firefox's source code and
for almost everything they have automated tests. When covered it
shouldn't be a big deal.

That's something the browser vendor should comment, maybe not the
WHATWG? Or are employers of browser vendors here in this discussion?

>
>> 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.
> Possibly. Should that usage become common, I'm sure your request will
> be reconsidered.

How can I be involved and help with the discussion? Where is the
official WHATWG group? Do they meet regularly?

>
>> Really, it would be awesome if JavaScript could read the HTTP status code!
> I agree. But there are plenty of other things which would also be
> awesome were they added to the platform and would enable use cases
> which cannot be hacked around server side, or would enable more common
> use cases.
>
> Hope this helps explain why there are little chances of this being
> implemented in the near future.

I totally respect that and can imagine that you have a very long queue
of feature requests.

But is there some kind of transparency? A platform where I can see all
the ideas, the requests and the process? Something like an issue tracker?

Cheers
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 Sunday, 25 May 2014 23:32:30 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC