- From: Michael Heuberger <michael.heuberger@binarykitchen.com>
- Date: Tue, 27 May 2014 14:12:47 +1200
- To: whatwg@lists.whatwg.org
Exactly :)
Thanks James!
On 27/05/14 14:06, James Greene wrote:
> 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
>>
>>
--
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:13:18 UTC