Re: [json] Re: jsonrequest and HTTP/1.1 message pipelining
- On Jan 2, 2008 11:15 AM, Mark Nottingham <mnot@...> wrote:
>Not all browsers support pipelining. Opera has it enabled, Firefox has
> Personally, I wouldn't go this way; you're making a bet that the
> overhead of setting up SSL/TLS is less than that of working
> synchronously. If you're just POSTing stuff to the server, combining
> several things into one request format may be the way to go.
> That having been said -- if you are going to use https, you'll need to
> have an API available that guarantees to give you a single connection
> back. XHR doesn't do that.
> I totally agree that pipelining is useful, and reducing latency is a
> good goal. It's just that the proper place to fix this sort of thing
> is lower in the stack, not higher.
> On 01/01/2008, at 7:24 AM, Tyler Close wrote:
> > Hi Mark,
> > I think message ordering and pipelining are really useful features, so
> > I'ld like to kick this around some more to see if there's something
> > that could work. For example, I've seen some web applications that
> > implement their own request boxcarring to compensate for the lack of
> > pipelining. At this point, they are basically tunneling their own
> > protocol through HTTP and so not getting many of the benefits of HTTP,
> > such as caching.
> > On Dec 18, 2007 9:06 PM, Mark Nottingham <mnot@...> wrote:
> > > There are several aspects, but if you have an outstanding request
> > on a
> > > connection, and another request is queued, deciding whether it's
> > more
> > > efficient to pipeline or to open a new connection (or, to wait for
> > > the other connection to clear) isn't always a simple thing to do. If
> > > the outstanding request takes a long time to process (either because
> > > the response is very large, or because it takes a lot of server-side
> > > processing time), it may be better to use your other connection.
> > Seems like this logic is something that should be expressed by the end
> > client. So if the client issued requests like:
> > JSONRequest.post(...);
> > JSONRequest.post(...);
> > it's saying there is no expected ordering and the browser should use
> > separate connections if possible. Whereas if the client issued
> > requests like:
> > var c = JSONRequest.ordered();
> > c.post(...);
> > c.post(...);
> > it's saying these requests must be ordered and the browser should
> > pipeline over a single connection if possible.
it disabled by default; The browser must be able to handle it
transparently to the JS app; Synchronous requests with browser-side
polling may benefit from pipelining; Pipelining effects are good only
for small-sized requests; So the browser should determine when to
pipeline or not (depending on immediately receiving the response
> > > > How about this: If there is no HTTP proxy, pipeline requests;--
> > > > otherwise, send the requests one at a time. So if the client asked
> > > > that requests be ordered, this is guaranteed and performance is
> > best
> > > > effort. If the client doesn't care about ordering, but wants best
> > > > performance, then it uses separately instantiated JSONRequest
> > objects.
> > > > Sound good?
> > > >
> > > You don't always know whether there's an intermediary there;
> > > interception proxies (aka "transparent proxies") and HTTP
> > accelerators
> > > aren't apparent to the client.
> > OK then, SSL to the rescue. For the case where the client asks that
> > requests be sent in order:
> > 1. If its an HTTPS connection, open a single connection and pipeline
> > the requests.
> > 2. Otherwise, open a single connection and send requests
> > synchronously.
> > For requests that don't use the ordered request API, they can be sent
> > as they currently are, over multiple connections.
> > This seems like a small amount of complexity to add, while gaining the
> > benefits of message ordering and pipelining when making secure
> > web-applications.
> > I suppose there could be some server-side infrastructure that again
> > "helps" the developer by re-ordering requests, but the web-application
> > developer is presumably in a better position to do something about
> > this. Are there any other gremlins?
> > Thanks,
> > --Tyler
> > --
> > Use web-keys for RESTful access-control:
> > http://waterken.sourceforge.net/
> > Name your trusted sites to distinguish them from phishing sites.
> > https://addons.mozilla.org/firefox/957/
> Mark Nottingham mnot@...