Re: [whatwg] HTTP status code from JavaScript
Exposing would be very useful to web application developers. Just to add some use cases. The Ruby on Rails framework automatically sets a header called X-Runtime to the number of milliseconds it took to render the body. Its pretty handily to get this value in JS and do a window.performance stats comparison against the backend render time. Today, you have to inject this stat into the footer of the html to expose it to JS. On Thu, May 22, 2014 at 10:36 PM, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Hello WhatWG There is a need to obtain the HTTP status code for the page itself from JavaScript: https://bugzilla.mozilla.org/show_bug.cgi?id=999886 I think this would be a great feature to save additional traffic in an already congested internet. Because I see lots of queries made by XMLHttpRequest solely to obtain the HTTP status code of the same URL. If the global browser variable (JavaScript) would already hold the status code, then these queries would become obsolete and the internet becomes a bit less blocked. Let me know how to proceed with my proposal within WhatWG. Greetings from Auckland, Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
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
Re: [whatwg] HTTP status code from JavaScript
David, you have very good points here. See below: ... 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. I'd agree 100% with you with this approach if it were not a Single Page App. Showing the relevant information to the user is decided on the client-side of my code! Not on the server. Hence the client-side code aka Javascript needs to know the status code. That's my problem. 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. With hacks I meant smuggling the HTTP status code inside a meta tag. 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. Oh no, I need it badly on the client-side. I raised a couple of examples and reasons in my earlier emails. 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
Re: [whatwg] HTTP status code from JavaScript
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 bruan...@gmail.com mailto:bruan...@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,
Re: [whatwg] HTTP status code from JavaScript
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.heuber...@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 bruan...@gmail.com
mailto:bruan...@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.
Re: [whatwg] HTTP status code from JavaScript
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.heuber...@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 bruan...@gmail.com
mailto:bruan...@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
Re: [whatwg] HTTP status code from JavaScript
Hi Michael, On Sun, May 25, 2014 at 3:10 PM, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Hi David Interesting. Yes and no, I agree with some. See my comments below: On 25/05/14 06:53, David Bruant wrote: Le 23/05/2014 10:04, Michael Heuberger a écrit : - 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. single page app usually means that no interaction in a given page will trigger a navigation (as long as there is JavaScript. A good SPA will fallback to using links and forms if there is a problem with JS). It does not mean that all HTML templates are on the client nor that you serve the exact same thing for every URL be they 200s or 404s. That's an definitely an option, but it's one you impose upon yourself. I understand. Okay we could debate about the definition of SPA. For fallbacks and special cases I deliver special files from the server when JS is disabled. But I think the definition of SPA nor its special cases are the main issue here. Look at Angular, their templates reside on the client side. For production, a grunt task can compress all files into one single, huge JS file that is served to the client, then for any subsequent pages no more resources are loaded from the server. It is a widely used practice. If you're creating your JS file on the server and pulling in all resources then, surely you can find out already at that time whether a piece is missing and can't be loaded? That's not a client side issue, but something that you'll need to deal with on the server. Silvia. Also I mentioned earlier, PhoneGap is getting more popular and exactly uses the architecture I have described. Again, I cannot emphasize how cool it would be to obtain the HTTP status code from JavaScript! It would save SPAs and PhoneGap projects some bandwidth. 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. 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. This is better than letting the user wait about 700ms until the user sees something on the screen. On this topic, I recommend watching [1] which introduces the idea of critical rendering path. Given your focus on performance and preventing wasted bandwidth, I think you'll be interested. Thanks for the link but I am Deaf and do not understand what they talk on YouTube :( 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. If all the HTML resides in the app, not on the server, then it wasn't served via HTTP, so there is no 200 or 404 to inform about (since no HTTP request occured). Ah, well spotted. PhoneGap comes with two options: a) You can choose to reside the whole HTML in the app or b) have it served from the server during the first HTTP request. Option a) saved bandwidth but you cannot update pages easily (option b). Option a) wouldn't need to know if it's a 200 or 404, you are right. Still, option b) needs to know the status code. Let me ask you another question: Is there a good reason NOT to give JavaScript a chance to find out the HTTP status code of the current page? Cheers Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
Thanks Silvia for your comment but I think we turn in circles. I know you mean it well but this is not the case as I mentioned it over and over again in my previous emails. Let me repeat, the whole SPA of mine is always loaded, no matter if it's a 404 or not so that a nice 404 can be rendered on the client-side. No piece is missing here. To make this work, Javascript needs to be able to have access to the HTTP status code of the initial page load. I can count more reasons or read my previous emails. Something like `window.http.status` would be really awesome. On 25/05/14 18:16, Silvia Pfeiffer wrote: Hi Michael, On Sun, May 25, 2014 at 3:10 PM, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Hi David Interesting. Yes and no, I agree with some. See my comments below: On 25/05/14 06:53, David Bruant wrote: Le 23/05/2014 10:04, Michael Heuberger a écrit : - 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. single page app usually means that no interaction in a given page will trigger a navigation (as long as there is JavaScript. A good SPA will fallback to using links and forms if there is a problem with JS). It does not mean that all HTML templates are on the client nor that you serve the exact same thing for every URL be they 200s or 404s. That's an definitely an option, but it's one you impose upon yourself. I understand. Okay we could debate about the definition of SPA. For fallbacks and special cases I deliver special files from the server when JS is disabled. But I think the definition of SPA nor its special cases are the main issue here. Look at Angular, their templates reside on the client side. For production, a grunt task can compress all files into one single, huge JS file that is served to the client, then for any subsequent pages no more resources are loaded from the server. It is a widely used practice. If you're creating your JS file on the server and pulling in all resources then, surely you can find out already at that time whether a piece is missing and can't be loaded? That's not a client side issue, but something that you'll need to deal with on the server. Silvia. Also I mentioned earlier, PhoneGap is getting more popular and exactly uses the architecture I have described. Again, I cannot emphasize how cool it would be to obtain the HTTP status code from JavaScript! It would save SPAs and PhoneGap projects some bandwidth. 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. 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. This is better than letting the user wait about 700ms until the user sees something on the screen. On this topic, I recommend watching [1] which introduces the idea of critical rendering path. Given your focus on performance and preventing wasted bandwidth, I think you'll be interested. Thanks for the link but I am Deaf and do not understand what they talk on YouTube :( 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. If all the HTML resides in the app, not on the server, then it wasn't served via HTTP, so there is no 200 or 404 to inform about (since no HTTP request occured). Ah, well spotted. PhoneGap comes with two options: a) You can choose to reside the whole HTML in the app or b) have it served from the server during the first HTTP request. Option a) saved bandwidth but you cannot update pages easily (option b). Option a) wouldn't need to know if it's a 200 or 404, you are right.
Re: [whatwg] HTTP status code from JavaScript
On May 25, 2014, at 8:59, Michael Heuberger
michael.heuber...@binarykitchen.com wrote:
Thanks Silvia for your comment but I think we turn in circles.
I know you mean it well but this is not the case as I mentioned it over
and over again in my previous emails.
Let me repeat, the whole SPA of mine is always loaded, no matter if it's
a 404 or not so that a nice 404 can be rendered on the client-side. No
piece is missing here. To make this work, Javascript needs to be able to
have access to the HTTP status code of the initial page load. I can
count more reasons or read my previous emails.
Something like `window.http.status` would be really awesome.
Why can't you just set that value server-side (e.g. In a meta tag or
even using a script tag) and retrieve it on the client? E.g. In pseudo
PHP:
scriptvar http = { status: ?php print response-status php};/script
--tobie
Re: [whatwg] HTTP status code from JavaScript
Hi Tobie
I've been thinking about that too before but IMO this is not clean for a
two reasons:
* It is a redundancy. The browser already knows the status code, just
not JavaScript.
* Adding inline JS script slows down the page load.
Believe me, I have asked many web developers around the globe, tweeted
about my idea and contacted Mozilla. Everyone thinks this would be a
great addition to JavaScript and there were no objections.
Tell me a good reason why JavaScript should NOT have access to the
status code?
On 25/05/14 19:09, Tobie Langel wrote:
On May 25, 2014, at 8:59, Michael Heuberger
michael.heuber...@binarykitchen.com wrote:
Thanks Silvia for your comment but I think we turn in circles.
I know you mean it well but this is not the case as I mentioned it over
and over again in my previous emails.
Let me repeat, the whole SPA of mine is always loaded, no matter if it's
a 404 or not so that a nice 404 can be rendered on the client-side. No
piece is missing here. To make this work, Javascript needs to be able to
have access to the HTTP status code of the initial page load. I can
count more reasons or read my previous emails.
Something like `window.http.status` would be really awesome.
Why can't you just set that value server-side (e.g. In a meta tag or
even using a script tag) and retrieve it on the client? E.g. In pseudo
PHP:
scriptvar http = { status: ?php print response-status php};/script
--tobie
--
Binary Kitchen
Michael Heuberger
4c Dunbar Road
Mt Eden
Auckland 1024
(New Zealand)
Mobile (text only) ... +64 21 261 89 81
Email mich...@binarykitchen.com
Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
Hi again, On May 25, 2014, at 9:35, Michael Heuberger michael.heuber...@binarykitchen.com wrote: * It is a redundancy. The browser already knows the status code, just not JavaScript. That argument can equally well be used the other way round: it's a redundancy to expose in JS something that be easily exposed by the server. * Adding inline JS script slows down the page load. In that case, use a meta tag: meta name=http-status content=404 Then in JS: var status = parseInt(document.querySelector(meta[name=http-status]).getAttribute(content)); Should this pattern become pervasive, it might bathe sense to standardize it and expose it in JS. Frankly, though, it's the first time I hear of such a request. --tobie
Re: [whatwg] HTTP status code from JavaScript
On 25 May 2014, at 09:58, Tobie Langel tobie.lan...@gmail.com wrote: * Adding inline JS script slows down the page load. In that case, use a meta tag: meta name=http-status content=404 Then in JS: var status = parseInt(document.querySelector(meta[name=http-status]).getAttribute(content)); Since `http-status` is not a registered metadata name (http://wiki.whatwg.org/wiki/MetaExtensions) it might be better to use a custom `data-*` attribute. It could be added to any element, e.g. body data-http-status=404 Then in JavaScript: var status = Number(document.body.dataset.httpStatus);
Re: [whatwg] HTTP status code from JavaScript
Hi Michael, Le 25/05/2014 07:10, Michael Heuberger a écrit : Look at Angular, their templates reside on the client side. For production, a grunt task can compress all files into one single, huge JS file that is served to the client, then for any subsequent pages no more resources are loaded from the server. It is a widely used practice. Look at React.js, it allows to render templates on the server side and it's been a selling point for some people (it allows to generate the same page whether you are on the client or server-side. It helps for SEO sometimes). Also I mentioned earlier, PhoneGap is getting more popular and exactly uses the architecture I have described. With application built with PhoneGap, the application (including the main HTML file) is downloaded once, so that's different from a webpage served from a server. 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). This is better than letting the user wait about 700ms until the user sees something on the screen. I'm proposing for the user to wait 0ms (ignoring uncompressible networking time of course) until the user sees something useful. On this topic, I recommend watching [1] which introduces the idea of critical rendering path. Given your focus on performance and preventing wasted bandwidth, I think you'll be interested. Thanks for the link but I am Deaf and do not understand what they talk on YouTube :( I apologize for mistakenly assuming video was a proper format for everyone to consume. You can find the slide deck at https://docs.google.com/presentation/d/1IRHyU7_crIiCjl0Gvue0WY3eY_eYvFQvSfwQouW9368/present#slide=id.p19 It should be self-sufficient. I'm happy to answer questions if it isn't. And credit where it's due, everytime I wrote above what I'm proposing it is just a reformulation of my understanding of Ilya Grigorik's presentation on the critical rendering path (I just add an emphasis on content). 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. If all the HTML resides in the app, not on the server, then it wasn't served via HTTP, so there is no 200 or 404 to inform about (since no HTTP request occured). Ah, well spotted. PhoneGap comes with two options: a) You can choose to reside the whole HTML in the app or b) have it served from the server during the first HTTP request. Option a) saved bandwidth but you cannot update pages easily (option b). Option a) wouldn't need to know if it's a 200 or 404, you are right. Still, option b) needs to know the status code. Option b) sounds like a bookmark, so it's a regular web page, so the arguments against stand (?) Let me ask you another question: Is there a good reason NOT to give JavaScript a chance to find out the HTTP status code of the current page? By that argument, an absurd amount of features should go in ;-) From a technical standpoint, I see no strong reason to not provide the HTTP status code. From a more social standpoint, it bothers me, because it means people serve the exact same content for all URLs, which defeats the very purpose of why URLs were invented in the first place. 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 #
Re: [whatwg] HTTP status code from JavaScript
Bonjour David On 25/05/14 23:33, David Bruant wrote: Hi Michael, Le 25/05/2014 07:10, Michael Heuberger a écrit : Look at Angular, their templates reside on the client side. For production, a grunt task can compress all files into one single, huge JS file that is served to the client, then for any subsequent pages no more resources are loaded from the server. It is a widely used practice. Look at React.js, it allows to render templates on the server side and it's been a selling point for some people (it allows to generate the same page whether you are on the client or server-side. It helps for SEO sometimes). Yeah, each framework has it's own way - nevertheless, Angular is very popular these days. Also I mentioned earlier, PhoneGap is getting more popular and exactly uses the architecture I have described. With application built with PhoneGap, the application (including the main HTML file) is downloaded once, so that's different from a webpage served from a server. 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. This is better than letting the user wait about 700ms until the user sees something on the screen. I'm proposing for the user to wait 0ms (ignoring uncompressible networking time of course) until the user sees something useful. Huh, 0ms? Database queries take some time ... ... but that's not the issue here. Let's stick to the topic please :) On this topic, I recommend watching [1] which introduces the idea of critical rendering path. Given your focus on performance and preventing wasted bandwidth, I think you'll be interested. Thanks for the link but I am Deaf and do not understand what they talk on YouTube :( I apologize for mistakenly assuming video was a proper format for everyone to consume. You can find the slide deck at https://docs.google.com/presentation/d/1IRHyU7_crIiCjl0Gvue0WY3eY_eYvFQvSfwQouW9368/present#slide=id.p19 It should be self-sufficient. I'm happy to answer questions if it isn't. No problem, you couldn't know before that I am Deaf. Thanks, will study these slides tomorrow. And credit where it's due, everytime I wrote above what I'm proposing it is just a reformulation of my understanding of Ilya Grigorik's presentation on the critical rendering path (I just add an emphasis on content). 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. If all the HTML resides in the app, not on the server, then it wasn't served via HTTP, so there is no 200 or 404 to inform about (since no HTTP request occured). Ah, well spotted. PhoneGap comes with two options: a) You can choose to reside the whole HTML in the app or b) have it served from the server during the first HTTP request. Option a) saved bandwidth but you cannot update pages easily (option b). Option a) wouldn't need to know if it's a 200 or 404, you are right. Still, option b) needs to know the status code. Option b) sounds like a bookmark, so it's a regular web page, so the arguments against stand (?) Yes like a bookmark. And that's a case where it would be great to read the HTTP status code from JavaScript. Let me ask you another question: Is there a good reason NOT to give JavaScript a chance to find out the HTTP status code of the current page? By that
Re: [whatwg] HTTP status code from JavaScript
Le 25/05/2014 14:04, Michael Heuberger a écrit : Bonjour David On 25/05/14 23:33, David Bruant wrote: Hi Michael, Le 25/05/2014 07:10, Michael Heuberger a écrit : Look at Angular, their templates reside on the client side. For production, a grunt task can compress all files into one single, huge JS file that is served to the client, then for any subsequent pages no more resources are loaded from the server. It is a widely used practice. Look at React.js, it allows to render templates on the server side and it's been a selling point for some people (it allows to generate the same page whether you are on the client or server-side. It helps for SEO sometimes). Yeah, each framework has it's own way - nevertheless, Angular is very popular these days. these days is not an argument. We're discussing an addition to the web platform and as we know, things are hard to remove after they've been added [1]. Frameworks come and go, the platform stays (so far at least) 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. 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. If all the HTML resides in the app, not on the server, then it wasn't served via HTTP, so there is no 200 or 404 to inform about (since no HTTP request occured). Ah, well spotted. PhoneGap comes with two options: a) You can choose to reside the whole HTML in the app or b) have it served from the server during the first HTTP request. Option a) saved bandwidth but you cannot update pages easily (option b). Option a) wouldn't need to know if it's a 200 or 404, you are right. Still, option b) needs to know the status code. Option b) sounds like a bookmark, so it's a regular web page, so the arguments against stand (?) Yes like a bookmark. And that's a case where it would be great to read the HTTP status code from JavaScript. Continuing the argument from above, the bookmark is to a specific URL and so, for the sake of bandwidth and UX, you should be serving different content for different URLs, so you don't need the HTTP status code Let me ask you another question: Is there a good reason NOT to give JavaScript a chance to find out the HTTP status code of the current page? By that argument, an absurd amount of features should go in ;-) Really? How many absurd amount of features do you guys get every day? http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-May/296902.html ? This suggestion is mostly harmless, but doesn't really add value in my opinion. I am less active on standards mailing-lists these days, so I cannot count, but others will know better. From a more social standpoint, it bothers me, because it means people serve the exact same content for all URLs, which defeats the very purpose of why URLs were invented in the first place. Ummm, I am not sure if I can follow you. What do you mean
Re: [whatwg] HTTP status code from JavaScript
On Sun, May 25, 2014 at 8:34 AM, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Tell me a good reason why JavaScript should NOT have access to the status code? There's always a good reason not to add new things. Call it inertia; every new feature starts at -100 points. Something like this, which gives you information you should already know and is only helpful when you've already made some seriously questionable design decisions, probably shouldn't ever overcome that initial deficit. Of course, that's just my opinion, but I have a feeling I'm not the only one.
Re: [whatwg] HTTP status code from JavaScript
On Sun, May 25, 2014 at 7:48 AM, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Hi Tobie * It is a redundancy. The browser already knows the status code, just not JavaScript. That argument can equally well be used the other way round: it's a redundancy to expose in JS something that be easily exposed by the server. I understand your perspective but you cannot compare two entirely different things. Don't forget that most modern web apps are 99% driven by JavaScript. If the server returns a 404, JavaScript is still unable to read the initial HTTP status code. Think about it :) The web server sends you back a response. It first sends the response code, then the response headers, then the response body. If you can alter the response code from the server, why can't you alter the response body? * Adding inline JS script slows down the page load. In that case, use a meta tag: meta name=http-status content=404 Then in JS: var status = parseInt(document.querySelector(meta[name=http-status]).getAttribute(content)); Should this pattern become pervasive, it might bathe sense to standardize it and expose it in JS. Frankly, though, it's the first time I hear of such a request. That would work but is an overhead, a redundancy. Why add another meta tag if the status code is already in the HTTP header?? Yes, it's interesting why nobody has suggested this before. There is always a first time. Probably I am the first to ask for this feature because I've been working heavily with SPA's and node.js in the recent years. Really, it would be awesome if JavaScript could read the HTTP status code! Yes, ideally the initial request to the server would be accessible to the script, including the response code, response headers, and so on (document.initialRequest returns an XMLHttpRequest-like object that's already completed?) At the same time, in order to deploy to sites without this feature, you'd need to be able to modify the response body accordingly as well. I think it makes sense to simply do that too. What server are you using here? Does it have a way of configuring it to modify the response codes for certain requests, but not the response body? Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com -- Jasper
Re: [whatwg] HTTP status code from JavaScript
Hi Tobie On 26/05/14 00:51, Tobie Langel wrote: On May 25, 2014, at 13:48, Michael Heuberger michael.heuber...@binarykitchen.com wrote: * It is a redundancy. The browser already knows the status code, just not JavaScript. That argument can equally well be used the other way round: it's a redundancy to expose in JS something that be easily exposed by the server. I understand your perspective but you cannot compare two entirely different things. Don't forget that most modern web apps are 99% driven by JavaScript. That's data's made and far from the truth. :-) Okay, I do not know the exact percentage but it is definitely a very high number. All I wanted is to emphasize how important JavaScript is these days. Getting more and more popular. If the server returns a 404, JavaScript is still unable to read the initial HTTP status code. Think about it :) How so? What prevents the server from adding a 404 status code in HTML markup? I already explained this in a previous email. Should I repeat it here? In short: it's a redundancy when the same information is already sent in the HTTP header. * Adding inline JS script slows down the page load. In that case, use a meta tag: meta name=http-status content=404 Then in JS: var status = parseInt(document.querySelector(meta[name=http-status]).getAttribute(content)); Should this pattern become pervasive, it might bathe sense to standardize it and expose it in JS. Frankly, though, it's the first time I hear of such a request. That would work but is an overhead, a redundancy. Why add another meta tag if the status code is already in the HTTP header?? This would be an overhead for *your* application. But adding code that's very much specific to your use case to the whole platform creates overhead for browser vendors which have to implement and maintain that code. Overhead? I am not so sure about that. I saw Firefox's source code and for almost everything they have automated tests. When covered it shouldn't be a big deal. That's something the browser vendor should comment, maybe not the WHATWG? Or are employers of browser vendors here in this discussion? Yes, it's interesting why nobody has suggested this before. There is always a first time. Probably I am the first to ask for this feature because I've been working heavily with SPA's and node.js in the recent years. Possibly. Should that usage become common, I'm sure your request will be reconsidered. How can I be involved and help with the discussion? Where is the official WHATWG group? Do they meet regularly? Really, it would be awesome if JavaScript could read the HTTP status code! I agree. But there are plenty of other things which would also be awesome were they added to the platform and would enable use cases which cannot be hacked around server side, or would enable more common use cases. Hope this helps explain why there are little chances of this being implemented in the near future. I totally respect that and can imagine that you have a very long queue of feature requests. But is there some kind of transparency? A platform where I can see all the ideas, the requests and the process? Something like an issue tracker? Cheers Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
Hi David Look at Angular, their templates reside on the client side. For production, a grunt task can compress all files into one single, huge JS file that is served to the client, then for any subsequent pages no more resources are loaded from the server. It is a widely used practice. Look at React.js, it allows to render templates on the server side and it's been a selling point for some people (it allows to generate the same page whether you are on the client or server-side. It helps for SEO sometimes). Yeah, each framework has it's own way - nevertheless, Angular is very popular these days. these days is not an argument. We're discussing an addition to the web platform and as we know, things are hard to remove after they've been added [1]. Frameworks come and go, the platform stays (so far at least) Exactly. The platform stays. That's why I do not want to hack the HTTP status code inside the meta tags through my framework. What I meant with Angular's popularity is that JavaScript and SPAs are popular. 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). 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. 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. If all the HTML resides in the app, not on the server, then it wasn't served via HTTP, so there is no 200 or 404 to inform about (since no HTTP request occured). Ah, well spotted. PhoneGap comes with two options: a) You can choose to reside the whole HTML in the app or b) have it served from the server during the first HTTP request. Option a) saved bandwidth but you cannot update pages easily (option b). Option a) wouldn't need to know if it's a 200 or 404, you are right. Still, option b) needs to know the status code. Option b) sounds like a bookmark, so it's a regular web page, so the arguments against stand (?) Yes like a bookmark. And that's a case where it would be great to read the HTTP status code from JavaScript. Continuing the argument from above, the bookmark is to a specific URL and so, for the sake of bandwidth and UX, you should be serving different content for different URLs, so you don't need the HTTP status code Huh? For some you might be right but you probably have missed out the architecture of my case in my early emails. This won't work for me. Let me ask you another question: Is there a good reason NOT to give JavaScript a chance to find out the HTTP status code of the current page? By that argument, an absurd amount of features should go in ;-) Really? How many
Re: [whatwg] HTTP status code from JavaScript
Hi Qebui On 26/05/14 05:16, Qebui Nehebkau wrote: Tell me a good reason why JavaScript should NOT have access to the status code? There's always a good reason not to add new things. Call it inertia; every new feature starts at -100 points. Something like this, which gives you information you should already know and is only helpful when you've already made some seriously questionable design decisions, probably shouldn't ever overcome that initial deficit. Of course, that's just my opinion, but I have a feeling I'm not the only one. That's an interesting point of view and I might agree with it for some issues. But not this one. Javascript does not have the information, the HTTP status code, we already know (in the HTTP header). To be correct, JavaScript is unable to read the HTTP header. The information is already there, just not accessible. The browser scans the HTTP header. Why not pass it along to JavaScript? IMO this is not really adding a new thing but opening a door. Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
Hi Jasper On 26/05/14 08:09, Jasper St. Pierre wrote: * It is a redundancy. The browser already knows the status code, just not JavaScript. That argument can equally well be used the other way round: it's a redundancy to expose in JS something that be easily exposed by the server. I understand your perspective but you cannot compare two entirely different things. Don't forget that most modern web apps are 99% driven by JavaScript. If the server returns a 404, JavaScript is still unable to read the initial HTTP status code. Think about it :) The web server sends you back a response. It first sends the response code, then the response headers, then the response body. If you can alter the response code from the server, why can't you alter the response body? I know that my dear :) Whatever we alter on the server, Javascript on the client-side is still unable to read the HTTP status code. I already mentioned in earlier emails that altering the response body is a redundancy. The information is already in the header. * Adding inline JS script slows down the page load. In that case, use a meta tag: meta name=http-status content=404 Then in JS: var status = parseInt(document.querySelector(meta[name=http-status]).getAttribute(content)); Should this pattern become pervasive, it might bathe sense to standardize it and expose it in JS. Frankly, though, it's the first time I hear of such a request. That would work but is an overhead, a redundancy. Why add another meta tag if the status code is already in the HTTP header?? Yes, it's interesting why nobody has suggested this before. There is always a first time. Probably I am the first to ask for this feature because I've been working heavily with SPA's and node.js in the recent years. Really, it would be awesome if JavaScript could read the HTTP status code! Yes, ideally the initial request to the server would be accessible to the script, including the response code, response headers, and so on (document.initialRequest returns an XMLHttpRequest-like object that's already completed?) I have never seen document.initialRequest before. At the same time, in order to deploy to sites without this feature, you'd need to be able to modify the response body accordingly as well. I think it makes sense to simply do that too. What server are you using here? Does it have a way of configuring it to modify the response codes for certain requests, but not the response body? nginx + node.js with ExpressJS Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
You might want to review http://wiki.whatwg.org/wiki/FAQ . In particular: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F HTH, Silvia. On Mon, May 26, 2014 at 10:02 AM, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Hi Jasper On 26/05/14 08:09, Jasper St. Pierre wrote: * It is a redundancy. The browser already knows the status code, just not JavaScript. That argument can equally well be used the other way round: it's a redundancy to expose in JS something that be easily exposed by the server. I understand your perspective but you cannot compare two entirely different things. Don't forget that most modern web apps are 99% driven by JavaScript. If the server returns a 404, JavaScript is still unable to read the initial HTTP status code. Think about it :) The web server sends you back a response. It first sends the response code, then the response headers, then the response body. If you can alter the response code from the server, why can't you alter the response body? I know that my dear :) Whatever we alter on the server, Javascript on the client-side is still unable to read the HTTP status code. I already mentioned in earlier emails that altering the response body is a redundancy. The information is already in the header. * Adding inline JS script slows down the page load. In that case, use a meta tag: meta name=http-status content=404 Then in JS: var status = parseInt(document.querySelector(meta[name=http-status]).getAttribute(content)); Should this pattern become pervasive, it might bathe sense to standardize it and expose it in JS. Frankly, though, it's the first time I hear of such a request. That would work but is an overhead, a redundancy. Why add another meta tag if the status code is already in the HTTP header?? Yes, it's interesting why nobody has suggested this before. There is always a first time. Probably I am the first to ask for this feature because I've been working heavily with SPA's and node.js in the recent years. Really, it would be awesome if JavaScript could read the HTTP status code! Yes, ideally the initial request to the server would be accessible to the script, including the response code, response headers, and so on (document.initialRequest returns an XMLHttpRequest-like object that's already completed?) I have never seen document.initialRequest before. At the same time, in order to deploy to sites without this feature, you'd need to be able to modify the response body accordingly as well. I think it makes sense to simply do that too. What server are you using here? Does it have a way of configuring it to modify the response codes for certain requests, but not the response body? nginx + node.js with ExpressJS Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
Thanks heaps! On 26/05/14 12:29, Silvia Pfeiffer wrote: You might want to review http://wiki.whatwg.org/wiki/FAQ . In particular: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F HTH, Silvia. On Mon, May 26, 2014 at 10:02 AM, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Hi Jasper On 26/05/14 08:09, Jasper St. Pierre wrote: * It is a redundancy. The browser already knows the status code, just not JavaScript. That argument can equally well be used the other way round: it's a redundancy to expose in JS something that be easily exposed by the server. I understand your perspective but you cannot compare two entirely different things. Don't forget that most modern web apps are 99% driven by JavaScript. If the server returns a 404, JavaScript is still unable to read the initial HTTP status code. Think about it :) The web server sends you back a response. It first sends the response code, then the response headers, then the response body. If you can alter the response code from the server, why can't you alter the response body? I know that my dear :) Whatever we alter on the server, Javascript on the client-side is still unable to read the HTTP status code. I already mentioned in earlier emails that altering the response body is a redundancy. The information is already in the header. * Adding inline JS script slows down the page load. In that case, use a meta tag: meta name=http-status content=404 Then in JS: var status = parseInt(document.querySelector(meta[name=http-status]).getAttribute(content)); Should this pattern become pervasive, it might bathe sense to standardize it and expose it in JS. Frankly, though, it's the first time I hear of such a request. That would work but is an overhead, a redundancy. Why add another meta tag if the status code is already in the HTTP header?? Yes, it's interesting why nobody has suggested this before. There is always a first time. Probably I am the first to ask for this feature because I've been working heavily with SPA's and node.js in the recent years. Really, it would be awesome if JavaScript could read the HTTP status code! Yes, ideally the initial request to the server would be accessible to the script, including the response code, response headers, and so on (document.initialRequest returns an XMLHttpRequest-like object that's already completed?) I have never seen document.initialRequest before. At the same time, in order to deploy to sites without this feature, you'd need to be able to modify the response body accordingly as well. I think it makes sense to simply do that too. What server are you using here? Does it have a way of configuring it to modify the response codes for certain requests, but not the response body? nginx + node.js with ExpressJS Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@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 mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
Michael, A praise for more than HTTP status code. Le 23 mai 2014 à 12:36, Michael Heuberger michael.heuber...@binarykitchen.com a écrit : There is a need to obtain the HTTP status code for the page itself from JavaScript: https://bugzilla.mozilla.org/show_bug.cgi?id=999886 We could do better. HTTP Code is yet another very specific bit of information. A question which is very often asked is how to access the HTTP headers from JavaScript without having to go through a round trip of XMLHttpRequest. http://stackoverflow.com/questions/220231/accessing-the-web-pages-http-headers-in-javascript I wish indeed that in the DOM there would be a way to access a JSON object with the full HTTP response headers and status line included. One of the reasons to record the full response instead of having to create an additional request is that some headers are time sensitive and some servers are very sensitive to the type of requests made. For example, some servers will (wrongly) send a different response for headers and/or status line if the HTTP request is made with a GET or a HEAD. -- Karl Dubost http://www.la-grange.net/karl/
Re: [whatwg] HTTP status code from JavaScript
Wonderful, great input Karl, thanks! Very true about the sensitiveness of the servers. Yes, accessing the HTTP headers directly from DOM would be awesome (without the need for an additional request!) On 26/05/14 13:10, Karl Dubost wrote: Michael, A praise for more than HTTP status code. Le 23 mai 2014 à 12:36, Michael Heuberger michael.heuber...@binarykitchen.com a écrit : There is a need to obtain the HTTP status code for the page itself from JavaScript: https://bugzilla.mozilla.org/show_bug.cgi?id=999886 We could do better. HTTP Code is yet another very specific bit of information. A question which is very often asked is how to access the HTTP headers from JavaScript without having to go through a round trip of XMLHttpRequest. http://stackoverflow.com/questions/220231/accessing-the-web-pages-http-headers-in-javascript I wish indeed that in the DOM there would be a way to access a JSON object with the full HTTP response headers and status line included. One of the reasons to record the full response instead of having to create an additional request is that some headers are time sensitive and some servers are very sensitive to the type of requests made. For example, some servers will (wrongly) send a different response for headers and/or status line if the HTTP request is made with a GET or a HEAD. -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
Le 23/05/2014 10:04, Michael Heuberger a écrit : - 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. single page app usually means that no interaction in a given page will trigger a navigation (as long as there is JavaScript. A good SPA will fallback to using links and forms if there is a problem with JS). It does not mean that all HTML templates are on the client nor that you serve the exact same thing for every URL be they 200s or 404s. That's an definitely an option, but it's one you impose upon yourself. 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. On this topic, I recommend watching [1] which introduces the idea of critical rendering path. Given your focus on performance and preventing wasted bandwidth, I think you'll be interested. 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. If all the HTML resides in the app, not on the server, then it wasn't served via HTTP, so there is no 200 or 404 to inform about (since no HTTP request occured). David [1] http://www.youtube.com/watch?v=PkOBnYxqj3klist=PLS3jzvALRSe6uP9gVfXLCG6nWo7M0hAJYfeature=shareindex=2
Re: [whatwg] HTTP status code from JavaScript
Hi David Interesting. Yes and no, I agree with some. See my comments below: On 25/05/14 06:53, David Bruant wrote: Le 23/05/2014 10:04, Michael Heuberger a écrit : - 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. single page app usually means that no interaction in a given page will trigger a navigation (as long as there is JavaScript. A good SPA will fallback to using links and forms if there is a problem with JS). It does not mean that all HTML templates are on the client nor that you serve the exact same thing for every URL be they 200s or 404s. That's an definitely an option, but it's one you impose upon yourself. I understand. Okay we could debate about the definition of SPA. For fallbacks and special cases I deliver special files from the server when JS is disabled. But I think the definition of SPA nor its special cases are the main issue here. Look at Angular, their templates reside on the client side. For production, a grunt task can compress all files into one single, huge JS file that is served to the client, then for any subsequent pages no more resources are loaded from the server. It is a widely used practice. Also I mentioned earlier, PhoneGap is getting more popular and exactly uses the architecture I have described. Again, I cannot emphasize how cool it would be to obtain the HTTP status code from JavaScript! It would save SPAs and PhoneGap projects some bandwidth. 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. 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. This is better than letting the user wait about 700ms until the user sees something on the screen. On this topic, I recommend watching [1] which introduces the idea of critical rendering path. Given your focus on performance and preventing wasted bandwidth, I think you'll be interested. Thanks for the link but I am Deaf and do not understand what they talk on YouTube :( 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. If all the HTML resides in the app, not on the server, then it wasn't served via HTTP, so there is no 200 or 404 to inform about (since no HTTP request occured). Ah, well spotted. PhoneGap comes with two options: a) You can choose to reside the whole HTML in the app or b) have it served from the server during the first HTTP request. Option a) saved bandwidth but you cannot update pages easily (option b). Option a) wouldn't need to know if it's a 200 or 404, you are right. Still, option b) needs to know the status code. Let me ask you another question: Is there a good reason NOT to give JavaScript a chance to find out the HTTP status code of the current page? Cheers Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
On 2014-05-23 06:53, Michael Heuberger wrote: Hi James Single page apps! These become more and more popular with frameworks like RactiveJS or AngularJS. There the first request is a HTTP request, for any subsequent requests an AJAX one is generated. The problem is the first HTTP AJAX requests are HTTP requests. I assume you mean the distinction between page navigation and using XMLHTTPRequest? request. The framework is unable to detect 404s with the first request because the status code cannot be obtained via JavaScript, hence a second request is made. If the initial page load yields a 404 will there be any scripts to execute at all? In my eyes, a waste of bandwidth. Cheers Michael Best regards, Julian
Re: [whatwg] HTTP status code from JavaScript
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 mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
- 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. - 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? (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.heuber...@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 mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
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.heuber...@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 mich...@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 mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
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.heuber...@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.heuber...@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 mich...@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 mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
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 silviapfeiff...@gmail.comwrote: 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.heuber...@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.heuber...@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 mich...@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 mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
Hi Silvia Yes, I know this trick but in my opinion it's a waste of bandwidth (a small one I know but multiply this with thousands of calls worldwide every hour ...) If we could obtain the status code from the first, raw HTTP request, then there is no need for this IMG trick anymore. Michael On 23/05/14 20:33, Silvia Pfeiffer 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.heuber...@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.heuber...@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 mich...@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 mich...@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 mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
I'm not opposed to this idea but... what Is a realistic use case for this? Sincerely, James Greene On Thu, May 22, 2014 at 10:36 PM, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Hello WhatWG There is a need to obtain the HTTP status code for the page itself from JavaScript: https://bugzilla.mozilla.org/show_bug.cgi?id=999886 I think this would be a great feature to save additional traffic in an already congested internet. Because I see lots of queries made by XMLHttpRequest solely to obtain the HTTP status code of the same URL. If the global browser variable (JavaScript) would already hold the status code, then these queries would become obsolete and the internet becomes a bit less blocked. Let me know how to proceed with my proposal within WhatWG. Greetings from Auckland, Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
