mike amundsen wrote:
Jonas:
Wouldn't that mean that it's the application (i.e. web page) and not the
client (i.e. browser) that decides to attempt compression or not? I.e. the
browser wouldn't try unless the web page had told it to do so.
Yes, if a flag is employed, the application code is
Jonas Sicking <[EMAIL PROTECTED]> wrote:
> This at the cost of the overhead of always making an OPTIONS request
> before attempting compression.
Only if you haven't seen the server before - and in the vast majority of
cases, you will have. I wouldn't suggest sending it every time, because
that
On Sep 11, 2008, at 22:59, Jonas Sicking wrote:
Wouldn't a better solution then be that when the web page sets the
flag on the XHR object the browser will always compress the data?
And leave it up to the web page to ensure that it doesn't enable
capabilities that the web server doesn't sup
Jonas:
> Wouldn't that mean that it's the application (i.e. web page) and not the
> client (i.e. browser) that decides to attempt compression or not? I.e. the
> browser wouldn't try unless the web page had told it to do so.
Yes, if a flag is employed, the application code is in control.
Again,
mike amundsen wrote:
Jonas:
In the text below I meant:
client = browser (or other hosting environment)
component = xmlHttpRequest (or XHR, etc.) object available as part of
the client/environment
application = code running within the client/environment (i.e. script
that can get an instance of
Jonas:
In the text below I meant:
client = browser (or other hosting environment)
component = xmlHttpRequest (or XHR, etc.) object available as part of
the client/environment
application = code running within the client/environment (i.e. script
that can get an instance of the component, etc.)
M
mike amundsen wrote:
Jonas:
Your proposal with the flag seems like it's reverting to the "having to
know" case, since you'd want to set the flag if and only if the server
supports compression to avoid extra overheads, while still taking advantage
of compression when the server supports it.
Jonas:
> Your proposal with the flag seems like it's reverting to the "having to
> know" case, since you'd want to set the flag if and only if the server
> supports compression to avoid extra overheads, while still taking advantage
> of compression when the server supports it.
Well, seems I've
mike amundsen wrote:
If i understand you, you're saying the coding of the page (HTML/JS)
should 'know' that the target server does/does-not support compression
for uploads and handle it accordingly. I assume you mean, for
example, as a coder, I know serverX only allows posting an XML
document,
If i understand you, you're saying the coding of the page (HTML/JS)
should 'know' that the target server does/does-not support compression
for uploads and handle it accordingly. I assume you mean, for
example, as a coder, I know serverX only allows posting an XML
document, while serverY only allo
mike amundsen wrote:
Jonas:
Good points.
Wouldn't a better solution then be that when the flag is set always
compress? And leave it up to the application to ensure that it doesn't
enable capabilities that the server doesn't support. After all, it's the
applications responsibility to know many
Jonas:
Good points.
> Wouldn't a better solution then be that when the flag is set always
> compress? And leave it up to the application to ensure that it doesn't
> enable capabilities that the server doesn't support. After all, it's the
> applications responsibility to know many other aspects o
mike amundsen wrote:
I think a reasonable approach would be to offer an optional flag to
*attempt* compression on the upload.
When set to "false" (the default), no OPTION call would be made and
the content would be sent w/o any compression.
When set to "true" the component can make an OPTIONS ca
I think a reasonable approach would be to offer an optional flag to
*attempt* compression on the upload.
When set to "false" (the default), no OPTION call would be made and
the content would be sent w/o any compression.
When set to "true" the component can make an OPTIONS call, inspect the
result
I think a reasonable approach would be to offer an optional flag to
*attempt* compression on the upload.
When set to "false" (the default), no OPTION call would be made and
the content would be sent w/o any compression.
When set to "true" the component can make an OPTIONS call, inspect the
result
Stewart Brodie wrote:
Jonas Sicking <[EMAIL PROTECTED]> wrote:
Stewart Brodie wrote:
I disagree with any proposal that allows the application layer to
forcibly interfere with the transports layer's internal workings. Use
of encodings, persistent connections, on-the-fly compression are
enti
Jonas Sicking <[EMAIL PROTECTED]> wrote:
> Stewart Brodie wrote:
> > I disagree with any proposal that allows the application layer to
> > forcibly interfere with the transports layer's internal workings. Use
> > of encodings, persistent connections, on-the-fly compression are
> > entirely inte
Kris Zyp wrote:
I suspect compression from the UA to the server will need support on
the XHR object in order to work. I don't think the right way to do
it is through setRequestHeader though, that seems like a hack at best.
I would have thought this would be negotiated by the server sending a
On Wed, Sep 10, 2008 at 7:10 AM, Kris Zyp <[EMAIL PROTECTED]> wrote:
> You are using an applet on the server to decode request entities sent from
> the browser?
by applet, i just mean something that does work but isn't the server
itself, i don't mean java (typically i'm using perl)
> Are you say
y Sneddon" <[EMAIL PROTECTED]>; "Dominique
Hazael-Massieux" <[EMAIL PROTECTED]>; "Boris Zbarsky" <[EMAIL PROTECTED]>;
Sent: Tuesday, September 09, 2008 5:00 PM
Subject: Re: Support for compression in XHR?
Kris Zyp wrote:
Well, at least when an o
Encoding capability isn't really a state in the HTTP sense,
since it is presumably an immutable characteristic of the server,
do you really know this? i could have an applet/script/application
which handles decoding of gz...
You are using an applet on the server to decode request entities se
On Wed, Sep 10, 2008 at 2:35 AM, Kris Zyp <[EMAIL PROTECTED]> wrote:
> Encoding capability isn't really a state in the HTTP sense,
> since it is presumably an immutable characteristic of the server,
do you really know this? i could have an applet/script/application
which handles decoding of gz...
I suspect compression from the UA to the server will need support on the
XHR object in order to work. I don't think the right way to do it is
through setRequestHeader though, that seems like a hack at best.
I would have thought this would be negotiated by the server sending a
Accept-Encoding
Kris Zyp wrote:
Well, at least when an outgoing XmlHttpRequest goes with a body, the
spec could require that upon setting the Content-Encoding header to
"gzip" or "deflate", that the body be adequately transformed. Or is
there another e.g. to POST a gzip request with Content-Encoding?
Why can
Well, at least when an outgoing XmlHttpRequest goes with a body, the
spec could require that upon setting the Content-Encoding header to
"gzip" or "deflate", that the body be adequately transformed. Or is
there another e.g. to POST a gzip request with Content-Encoding?
Why can it not just be a
Stewart Brodie wrote:
Dominique Hazael-Massieux <[EMAIL PROTECTED]> wrote:
Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit :
HTTP has Content-Encoding and Transfer-Encoding, no? No special effort
on the part of XMLHttpRequest is needed to make use of those, as long as
the
Geoffrey Sneddon wrote:
On 9 Sep 2008, at 14:58, Dominique Hazael-Massieux wrote:
Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit :
HTTP has Content-Encoding and Transfer-Encoding, no? No special effort
on the part of XMLHttpRequest is needed to make use of those, as long
Dominique Hazael-Massieux <[EMAIL PROTECTED]> wrote:
>
> Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit :
> > HTTP has Content-Encoding and Transfer-Encoding, no? No special effort
> > on the part of XMLHttpRequest is needed to make use of those, as long as
> > the underlying
On Tue, 09 Sep 2008 17:40:17 +0200, Dominique Hazael-Massieux <[EMAIL PROTECTED]>
wrote:
Le mardi 09 septembre 2008 à 17:37 +0200, Anne van Kesteren a écrit :
The specification states that user agents SHOULD set the Accept-Encoding
header and also states that encoded content MUST be decoded.
Le mardi 09 septembre 2008 à 17:37 +0200, Anne van Kesteren a écrit :
> On Tue, 09 Sep 2008 17:29:03 +0200, Dominique Hazael-Massieux <[EMAIL
> PROTECTED]>
> wrote:
> > I'm sure it could, but if one implementation does it and another
> > doesn't, this leads to interoperability problems - hence
On Tue, 09 Sep 2008 17:29:03 +0200, Dominique Hazael-Massieux <[EMAIL PROTECTED]>
wrote:
I'm sure it could, but if one implementation does it and another
doesn't, this leads to interoperability problems - hence the usefulness
of documenting it in the spec. Or this is there any catchall
require
Le mardi 09 septembre 2008 à 16:10 +0100, Geoffrey Sneddon a écrit :
> > Well, at least when an outgoing XmlHttpRequest goes with a body, the
> > spec could require that upon setting the Content-Encoding header to
> > "gzip" or "deflate", that the body be adequately transformed. Or is
> > there an
On 9 Sep 2008, at 14:58, Dominique Hazael-Massieux wrote:
Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit :
HTTP has Content-Encoding and Transfer-Encoding, no? No special
effort
on the part of XMLHttpRequest is needed to make use of those, as
long as
the underlying HTTP
Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit :
> HTTP has Content-Encoding and Transfer-Encoding, no? No special effort
> on the part of XMLHttpRequest is needed to make use of those, as long as
> the underlying HTTP implementation supports them.
Well, at least when an outgo
Dominique Hazael-Massieux wrote:
The Mobile Web Best Practices Working Group is interested to know
whether XmlHTTPRequest has any actual or planned support for compression
HTTP has Content-Encoding and Transfer-Encoding, no? No special effort
on the part of XMLHttpRequest is needed to make u
Hello WebApps WG,
The Mobile Web Best Practices Working Group is interested to know
whether XmlHTTPRequest has any actual or planned support for compression
- I looked quickly in the specs and issues list, but didn't find
anything relevant.
Thanks,
Dom
36 matches
Mail list logo
