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
stat
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
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 Mich
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 th
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 so
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 fig
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.
>
>
Michael,
A praise for more than HTTP status code.
Le 23 mai 2014 à 12:36, Michael Heuberger
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
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, Mic
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
wrote:
> Hi Jasper
>
> On 26/05/14 08:09, Jasper St. Pier
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
>
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
> info
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
Hi Tobie
On 26/05/14 00:51, Tobie Langel wrote:
> On May 25, 2014, at 13:48, Michael Heuberger
> 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
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 exp
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. Some
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, h
On May 25, 2014, at 13:48, Michael Heuberger
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.
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 clien
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 com
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
On 25 May 2014, at 09:58, Tobie Langel wrote:
>
>> * Adding inline JS
Hi again,
On May 25, 2014, at 9:35, Michael Heuberger
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.
>
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 slows down the page load.
Believe me, I have asked many web developers around the globe, tweeted
On May 25, 2014, at 8:59, Michael Heuberger
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 mat
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
Hi Michael,
On Sun, May 25, 2014 at 3:10 PM, Michael Heuberger
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 part
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 usabil
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
Exactly James.
Now that single page apps become more popular I think this won't be an
edge case in the near future.
Tell me how I can help WhatWG to work on this idea? How does the process
work?
Cheers
Michael
On 24/05/14 05:56, James Greene wrote:
> I think he wants to be able to serve the exa
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 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 us
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
>
> I
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,
> - 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 na
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
c
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
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
request. The framework is unable to detect 404s with the first
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
>
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
XMLHttpRequ
40 matches
Mail list logo