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: Fri, 23 May 2014 12:56:05 -0500
Message-ID: <CALrbKZjCqvOKQN3__6wxkJW+JpOjYH9Ktv_oUkdEh2eSM6A4Lw@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Michael Heuberger <michael.heuberger@binarykitchen.com>
I think he wants to be able to serve the exact same single page no matter
what the status code is (i.e. including `404`s) and then be able to react
to the initial page status code on the client-side.

A bit of an edge case as most people serve different pages with HTTP errors
but it is a logical use case.

Sincerely,
    James Greene



On Fri, May 23, 2014 at 3:33 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> I had to deal with this on a script created IMG element the other day. I
> used onerror  to deal with it.
> For xmlhttprequest you can use the status field.
> Why is that not enough?
>
> Silvia.
>  On 23 May 2014 18:06, "Michael Heuberger" <
> michael.heuberger@binarykitchen.com> wrote:
>
> > Good points Mat
> >
> > In theory you have good points but in the real world it is more
> > complicated than that. See my comments below:
> >
> > On 23/05/14 19:49, Mat Carey wrote:
> > >> - Notify the administrator about a 404 by email with a response back
> to
> > >> the server
> > > But the server already knows about the 404, JS shouldn’t be needed/used
> > to re-inform the server of the status it’s already sent.
> >
> > Nowadays you can access other entities directly, i.E. a RIAK Database
> > server which returns a 404 if the ID in the query does not exist which
> > can be a raw HTTP request. This without any app logic in-between.
> >
> > ... or you have a cloud with multiple servers but only one of them is
> > responsible for error reporting.
> >
> > It is just an example. I could count more use cases where the feature is
> > really needed.
> >
> > >> - Display a beautiful 404 page and hide parts of the navigation
> > >> - Reveal navigation history to give users a better usability
> experience
> > >> during 404s
> > >> - And many more …
> > > I agree with those entirely but couldn’t they also be achieved by
> > including the correct scripts on the 404 page issued from the server?
> >
> > No, it is a single page app. All the HTML templates are on the client
> > side and loaded once during page load. And everything happens
> > dynamically. In other words: You load everything once, then there is no
> > further interaction with the server unless it's a specific query for
> > data or alters data in the database.
> >
> > Furthermore you can convert a whole single page app into an iPhone app
> > with PhoneGap. All the HTML resides in the app, not on the server.
> > That's a very different approach and a good reason why JavaScript has
> > the right to know if the HTTP request resulted into a 200 or a 404.
> >
> > Cheers
> > Michael
> >
> > >
> > > (I’m not against the original suggestion, I just don’t think these
> > particular use-cases demand a new feature)
> > >
> > > Mat Carey
> > > 07952258096
> > >
> > > On 23 May 2014, at 07:52, Michael Heuberger <
> > michael.heuberger@binarykitchen.com> wrote:
> > >
> > >> Hi Julian
> > >>
> > >> Yes, with "AJAX" requests I meant using XMLHTTPRequest.
> > >>
> > >>> If the initial page load yields a 404 will there be any scripts to
> > >>> execute at all?
> > >> Oh yes, absolutely. Have you ever written a single page app? There is
> > >> lots of logic to execute when a 404 occurs. I could count plenty of
> use
> > >> cases and functions that make sense. Here some examples:
> > >> - Notify the administrator about a 404 by email with a response back
> to
> > >> the server
> > >> - Display a beautiful 404 page and hide parts of the navigation
> > >> - Reveal navigation history to give users a better usability
> experience
> > >> during 404s
> > >> - And many more ...
> > >>
> > >> All these above examples run on JavaScript. Because there is currently
> > >> no way for JavaScript to determine if the page load yielded a 404, a
> > >> subsequent request, namely a XMLHTTPRequest one is often added. In my
> > >> professional opinion a bad solution.
> > >>
> > >> Again, I strongly believe that this would be a huge improvement and
> > >> avoids unnecessary network traffic.
> > >>
> > >> 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
> > >>
> >
> > --
> >
> > 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 Friday, 23 May 2014 17:56:52 UTC

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