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
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
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
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
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
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
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
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
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
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,
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
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 =
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
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
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,
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.
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
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
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.
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
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
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
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
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
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
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
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
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
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
- 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
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
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
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
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
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
35 matches
Mail list logo
