- From: Michael Heuberger <michael.heuberger@binarykitchen.com>
- Date: Sat, 24 May 2014 13:21:36 +1200
- To: whatwg@lists.whatwg.org
Exactly James. Now that single page apps become more popular I think this won't be an edge case in the near future. Tell me how I can help WhatWG to work on this idea? How does the process work? Cheers Michael On 24/05/14 05:56, James Greene wrote: > 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 >>> >>> -- 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 Saturday, 24 May 2014 01:22:07 UTC