- From: James Greene <james.m.greene@gmail.com>
- Date: Mon, 26 May 2014 21:06:38 -0500
- To: Michael Heuberger <michael.heuberger@binarykitchen.com>
- Cc: WHATWG <whatwg@lists.whatwg.org>, Austin France <adf@sorcerer.co.uk>, David Bruant <bruant.d@gmail.com>
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
>
>
Received on Tuesday, 27 May 2014 02:07:05 UTC