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: Tue, 27 May 2014 14:12:47 +1200
Message-ID: <5383F49F.9010106@binarykitchen.com>
To: whatwg@lists.whatwg.org
Exactly :)

Thanks James!

On 27/05/14 14:06, James Greene wrote:
> I like the `window.http` idea mentioned earlier by Michael. Something like:
>
> ```js
> window.http = {
>   url: window.location.href,
>   status: 404,
>   headers: {
>     /* ... */
>   }
> };
> ```
>
> If implemented, this would also be easy to polyfill in older browsers using
> the duplicate AJAX request hack that Michael is using today (or a
> server-side generated inline script block if you want guaranteed
> correctness).
>
> Sincerely,
>     James Greene
>     Sent from my [smart?]phone
> On May 26, 2014 6:37 PM, "Michael Heuberger" <
> michael.heuberger@binarykitchen.com> wrote:
>
>> Yeah, something like that Austin.
>>
>> But like I mentioned, why add the status code inside the HTML code when
>> it's already available in the HTTP status header? Hence I raised
>> "redundancy" multiple times before.
>>
>> I could do that but not thanks. I still believe that JavaScript should
>> be able to parse the HTTP status headers.
>>
>> Cheers
>> Michael
>>
>> On 27/05/14 00:16, Austin France wrote:
>>> Hi from Random Observer
>>>
>>> Just trying to get my head around the requirement:-
>>>
>>> So we have an app that is served for any URL on the server (and so
>>> apart from the small html loader is only loaded for the initial
>>> request) and from that the server checks for the presence of the video
>>> and either returns a status 200 or 404 plus the app code which the
>>> javascript wants to use to display a video not available message or
>>> the video itself.  The URI of the video presumably being derived from
>>> the URI of the page (not by anything passed by the server).
>>>
>>> The requirement is to be able to indicate to the app that the video
>>> does not exist in the initial request without requiring any additional
>>> informationt be passed to the client.
>>>
>>> Having the status code available to javascript though would obviously
>>> be ideal in this kind of setup, however as each URI is still returning
>>> some html and I think the meta tag or body attribute suggestions
>>> previously mentioned a completely acceptable way to solve this issue
>>> (or variation of), I see it as a minor overhead.  <html status="404">
>>> sort of thing.
>>>
>>>
>>>
>>>
>>> Regards
>>> Austin
>>>
>>>
>>>
>>>
>>> On 26 May 2014 12:09, David Bruant <bruant.d@gmail.com
>>> <mailto:bruant.d@gmail.com>> wrote:
>>>
>>>     Le 26/05/2014 01:52, Michael Heuberger a écrit :
>>>
>>>                             Serving different content based on
>>>                             different URLs (and status)
>>>                             actually does make a lot of sense when you
>>>                             want your user to see the
>>>                             proper content within the first HTTP
>>>                             round-trip (which saves
>>>                             bandwidth). If you always serve generic
>>>                             content and figure it all out
>>>                             on the client side, then either you always
>>>                             need a second request to
>>>                             get the specific content or you're always
>>>                             sending useless data during
>>>                             the first generic response which is also
>>>                             wasted bandwidth.
>>>
>>>                         Good point. From that point of view I agree
>>>                         but you forgot one thing:
>>>                         The user experience. We want mobile apps to be
>>>                         very responsive below
>>>                         300ms.
>>>
>>>                     Agreed (on UX and responsive applications)
>>>
>>>                         Hence the two requests. The first one ensures
>>>                         the SPA to be
>>>                         loaded and the UI to be initialized. You'll
>>>                         see some animation, a text
>>>                         saying "Fetching data" whatever. Then the
>>>                         second request retrieves the
>>>                         specific content.
>>>
>>>                     What I'm proposing is that all the relevant
>>>                     content is served within
>>>                     the *first* request. The URL is used by the client
>>>                     to express to the
>>>                     server (with arbitrary granularity, it depends on
>>>                     your app, obviously)
>>>                     what the user wants.
>>>                     What I'm proposing is not two requests to get the
>>>                     proper content, but
>>>                     only one. The user doesn't even have to wait with
>>>                     a useless "Fetching
>>>                     data" screen; the useful content is just there
>>>                     within the first
>>>                     request (hence server-side rendering with React or
>>>                     Moustache or else
>>>                     being useful).
>>>
>>>                 Yeah of course I could do that too. It is
>>>                 psychologically proven that
>>>                 the subjective waiting time is shorter when you see
>>>                 something as soon as
>>>                 possible.
>>>
>>>             Yes and what I'm suggesting is providing actual content as
>>>             soon as
>>>             possible. The whole idea of the "critical rendering path"
>>>             is exactly
>>>             about engineering your webpage so useful content is
>>>             provided to the
>>>             user as soon as possible (which is as soon as you're
>>>             currently capable
>>>             of showing a "Fetching data" screen).
>>>
>>>             If you're being serious about bandwidth and UX (including
>>>             percieved
>>>             performance), it's exactly what you should be doing, I
>>>             believe.
>>>
>>>         I agree totally with you here. But again, I want to know the
>>>         404 in one
>>>         request, not within two requests (Ajax).
>>>
>>>     I am suggesting that you make a single request, not two.
>>>     You're focusing on the HTTP status code, but in the end the code
>>>     isn't important. Showing the relevant information to the user is
>>>     what's important. The status code (client-side or server-side) is
>>>     just a means to get there.
>>>     What I'm proposing is to bypass the "which status is it?" part to
>>>     get to the "show the relevant information to the user" part.
>>>
>>>
>>>         Isn't that a performance
>>>         optimization (regardless of your application architecture and
>>>         critical
>>>         rendering path)?
>>>
>>>         Still, the ability to read the HTTP status code from
>>>         JavaScript would
>>>         prevent me from doing "hacks".
>>>
>>>     I wouldn't consider showing the right content (that the link is
>>>     broken) to your users a hack.
>>>
>>>
>>>                 It is absolutely normal that URLs change or become
>>>                 invalid, hence the
>>>                 need for status codes. You know ...
>>>
>>>                     You want to serve the same content regardless of
>>>                     the URL and then have
>>>                     client-side code read the URL and change the page
>>>                     state based on the
>>>                     URL. We already have a standardized way to express
>>>                     a part of the URL
>>>                     that is only interpreted on the client side which
>>>                     is the hash
>>>                     (everything after '#'). Format your URLs using #
>>>                     if that's your
>>>                     intention.
>>>
>>>                 My single page app works without the # part and uses
>>>                 absolutely
>>>                 normal-looking URLs to make it easier for search
>>>                 engine to spider it.
>>>
>>>             Then why serving the exact content on every URL?
>>>
>>>         I don't do that :)
>>>
>>>     (I meant "exact same")
>>>     As far as the server is concerned, you're doing that. Otherwise,
>>>     you wouldn't be needing for the HTTP status on the client-side.
>>>
>>>
>>>                     Also, given that you always serve the same content
>>>                     and only figure
>>>                     things out on the client side, why does your
>>>                     server sometimes answer
>>>                     404? Deciding whether the URL is erroneous should
>>>                     occur on the
>>>                     client-side, no?
>>>                     Anyway, so far, what you're asking for seems like
>>>                     it's only
>>>                     encouraging misusage of existing technologies.
>>>
>>>                 Okay, I have a huge sign language video library here
>>>                 for Deaf people.
>>>                 Anyone can add / edit / delete stuff. Each video has
>>>                 an unique URL. When
>>>                 I load a page of a deleted video, a 404 is returned
>>>                 with the whole SPA
>>>                 code and additional stuff is rendered to deal with
>>>                 404s in a nice way to
>>>                 improve usability. Here you have a real-world example
>>>                 and it is not a
>>>                 misusage of technologies.
>>>
>>>             I still see a misuse of URLs.
>>>             Why aren't you serving a different page for 404s? The
>>>             perceived
>>>             performance would be better for your users.
>>>
>>>             Even if there is a way to read the HTTP status code, the
>>>             user has to
>>>             wait for:
>>>             1) the HTML + the SPA code to be downloaded
>>>             2) the SPA to read the HTTP status code, build the error page
>>>             3) display the error page
>>>
>>>             If you serve a different content on 404, the user has to
>> wait:
>>>             1) the HTML to be downloaded (which naturally displays the
>>>             page)
>>>             2) (then, you can improve the experience with the JS code
>>>             which
>>>             downloads while the user is reading that they're on the
>>>             wrong page)
>>>
>>>         Good summary! I've been thinking about this a lot before
>>>         myself and
>>>         tried it myself.
>>>
>>>         I didn't decide for the latter method because I wanted to
>>>         process /
>>>         treat all the pages the same way
>>>
>>>     (this is what I called above "serving the exact same content on
>>>     every URL")
>>>
>>>
>>>         without exceptions to keep the code on
>>>         the server side as simple as possible. And it would become too
>>>         complicated and really bad. When the HTML is downloaded, then
>>>         it is
>>>         rendered and as long as the JS code is not ready, you are in an
>>>         undefined state.
>>>
>>>         Also, think of other things i.E. navigation elements which are
>>>         totally
>>>         JS driven. I'd have to add more hacks, bend my framework to
>>>         make it work
>>>         for this case and so on. Just too complicated and cost more at
>>>         the end.
>>>
>>>         I want to treat all the pages the same way with "one" code.
>>>         This would
>>>         work if the HTTP status code is readable from within JavaScript.
>>>
>>>     That's the heart of the problem I believe. You trapped yourself
>>>     into some framework design choices and wish a change in the
>>>     platform to accomodate your current architecture; have the
>>>     platform pay for your technical debt in a way :-/
>>>
>>>     David
>>>
>>>
>> --
>>
>> 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 Tuesday, 27 May 2014 02:13:18 UTC

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