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.


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 <
> <>> 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 ................
Website ..............

Reply via email to