CODEWITHSUNDEEP
httphttp-headers
Malkocoglu
Malkocoglu

Reputation: 2611

Is there a HTTP header field / hack to tell the browser NOT to pipeline its requests?

I am implementing a minimalistic web server application on a Microcontroller. When I have several images (or CSS/JS) on the web page, the browser creates several connections and fetches them. But the Microcontroller can not catch up with this. Is there a way to tell the browser to stop pipelining and fetch them one by one ?

Note :: "Connection: close" is already in place.

Upvotes: 0

Views: 1213

Answers (3)

Alexander S.
Alexander S.

Reputation: 33

Same problem... However, Firefox loads my site very fast unlike Opera. I have not invented anything better than rejecting connections at an initial stage: SYN. I'm just answering with RST flag. But probably it doesn't suit Opera. My device supports only two simultaneous connections.

Upvotes: 1

Julian Reschke
Julian Reschke

Reputation: 42045

"Pipelining" is something else; it means that the user agent sends additional requests on the same connection although the first one didn't complete yet (see http://greenbytes.de/tech/webdav/rfc2616.html#pipelining).

"Connection: close" doesn't seem to be relevant; that being said: is there a reason why you don't want the connection reused?

With respect to your question: no, I don't think you can prevent clients from doing that. Did you try limiting the maximum number of open connections on your server?

Upvotes: 2

Martin v. Löwis
Martin v. Löwis

Reputation: 127467

I think Connection:close is exactly the wrong message. When the browser creates multiple connections, it precisely does not pipeline its requests - so ISTM that you want the browser to pipeline, instead of creating parallel connections.

So one step towards that would be to use HTTP 1.1, and keep the connection open. The browser would then reuse the TCP connection for further requests. This should allow the microcontroller to catch up.

Now, the browser might still try to create additional, parallel connections. The best reaction to that is to not accept any of these connections. So limit the number of parallel connections that you are serving (independent of client), and only read new requests when you are done reading the previous ones. In doing so, prefer to read from established connections over accepting new connections.

If you have access to the TCP stack of the controller, you might be able to tell what host a connection comes from, so you can accept connections from other browsers while limiting the number of connections from the same browser (something that you cannot do in the regular socket API).

Upvotes: 2

Related Questions