- From: James Greene <james.m.greene@gmail.com>
- Date: Fri, 23 May 2014 12:56:05 -0500
- 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