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

Re: [whatwg] HTTP status code from JavaScript

From: James Greene <james.m.greene@gmail.com>
Date: Mon, 26 May 2014 21:06:38 -0500
Message-ID: <CALrbKZiPvOSjXBFbTyX21D2oC_SSJOZYK+CbkMH6SixrLV6jYw@mail.gmail.com>
To: Michael Heuberger <michael.heuberger@binarykitchen.com>
Cc: WHATWG <whatwg@lists.whatwg.org>, Austin France <adf@sorcerer.co.uk>, David Bruant <bruant.d@gmail.com>
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
>
>
Received on Tuesday, 27 May 2014 02:07:05 UTC

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