Re: [whatwg] HTTP status code from JavaScript

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