52

My question might sound stupid, but I just wanted to be sure:

  • Is it possible to send an HTTP response before having the request for that resource?

Say for example you have an HTML page index.html that only shows a picture called img.jpg. Now, if your server knows that a visitor will request the HTML file and then the jpg image every time:

Would it be possible for the server to send the image just after the HTML file to save time?

I know that HTTP is a synchronous protocol, so in theory it should not work, but I just wanted someone to confirm it (or not).

Michael Myers
  • 188,989
  • 46
  • 291
  • 292
m_vdbeek
  • 3,704
  • 7
  • 46
  • 77
  • So your question is how to send the JPEG immediately after index.html without waiting for the browser to render the html page and request the JPEG? – Tim M. Sep 06 '12 at 02:28
  • Yes, exactly. Just a matter of saving time for stuff that is already determined. Like which CSS / JS files to load for that particular page ...etc. – m_vdbeek Sep 06 '12 at 02:31
  • HTTP/2 addresses this exact problem by adding the push ability; this requires the server to send BOTH the request and the corresponding response, allowing the client to cache it locally. Then, when the client requests the resource, it is satisfied by its local cache, incurring no network communication. In HTTP/1.1, however, sending predictive responses is highly inadvisable. – avakar Jan 28 '17 at 07:43

7 Answers7

23

A recent post by Jacques Mattheij, referencing your very question, claims that although HTTP was designed as a synchronous protocol, the implementation was not. In practise the browser (he doesn't specify which exactly) accepts answers to requests have not been sent yet.

On the other hand, if you are looking to something less hacky, you could have a look at :

  • push techniques that allows the server to send content to the browser. The modern implementation that replace long-polling/Comet "hacks" are the websockets. You may want to have a look at socket.io also.
  • Alternatively you may want to have a look at client-side routing. Some implementations combine this with caching techniques (like in derby.js I believe).
Community
  • 1
  • 1
nha
  • 17,623
  • 13
  • 87
  • 133
  • 1
    Any implementation will accept responses that were sent before the request was *read*, but only a pretty strange implementation would start reading the response before sending the request. – user207421 Jun 09 '14 at 23:53
  • Pretty strange indeed. And acknowledged by the post author many times : "the little bit of black magic", "the game would be up, this time they’d close the loophole", "we just got lucky that it worked and luckier still that it kept working as long as it did". That made it enjoyable to read besides being interesting. – nha Jun 14 '14 at 10:04
15

If someone requests /index.html and you send two responses (one for /index.html and the other for /img.jpg), how do you know the recipient will get the two responses and know what to do with them before the second request goes in?

The problem is not really with the sending. The problem is with the receiver possibly getting unexpected data.

One other issue is that you're denying the client the ability to use HTTP caching tools like If-Modified-Since and If-None-Match (i.e. the client might not want /img.jpg to be sent because it already has a cached copy).

That said, you can approximate the server-push benefits by using Comet techniques. But that is much more involved than simply anticipating incoming HTTP requests.

Dan Atkinson
  • 11,391
  • 14
  • 81
  • 114
Raymond Hettinger
  • 216,523
  • 63
  • 388
  • 485
  • Wouldn't TCP already reorder the responses in the lower levels ? I don't really understand the problem with caching though. – m_vdbeek Sep 06 '12 at 02:37
2

You'll get a better result by caching resources effectively, i.e. setting proper cache headers and configuring your web server for caching. You can also inline images using base 64 encoding, if that's a specific concern.

You can also look at long polling javascript solutions.

Community
  • 1
  • 1
Tim M.
  • 53,671
  • 14
  • 120
  • 163
  • Well yes, it's true that caching is really effective, but it's a separate way of reducing the time between the first request and the full page rendering with all the resources. Caching won't change the fact that the user still has to do a request and it is time lost that seemingly can't be reduced. – m_vdbeek Sep 06 '12 at 02:41
  • True...then look at inlining resources...you can include almost anything you want in a single request by making it part of the HTML document requested. – Tim M. Sep 06 '12 at 02:43
1

You're looking for server push: it isn't available in HTTP. Protocols like SPDY have it, but you're out of luck if you're restricted to HTTP.

Femi
  • 64,273
  • 8
  • 118
  • 148
1

I don't think it is possible to mix .html and image in the same HTTP response. As for sending image data 'immediately', right after the first request - there is a concept of 'static resources' which could be of help (but it will require client to create a new reqest for a specific resource).

There are couple of interesting things mentioned in the the article.

Maciek Talaska
  • 1,628
  • 1
  • 14
  • 22
  • not a problem - please note one of the most interesting things that developers tend to forget: due to asymetric speed of up & download sending a 0.5kb request could take as much time as downloading many more kilobytes of data from the server. – Maciek Talaska Sep 06 '12 at 02:45
-1

No it is not possible.

The first line of the request holds the resource being requested so you wouldn't know what to respond with unless you examined the bytes (at least one line's worth) of the request first.

Jason Fuerstenberg
  • 1,341
  • 13
  • 13
-2

No. HTTP is defined as a request/response protocol. One request: one response. Anything else is not HTTP, it is something else, and you would have to specify it properly and implement it completely at both ends.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • 1
    HTTP is defined as request->response, however it is entirely possible to send the response before the request, and this is used extensively in video streaming to send the next frame without waiting for the request. http://jacquesmattheij.com/the-several-million-dollar-bug – Nick Sweeting Jun 09 '14 at 12:00
  • 1
    @NickSweeting I would still define that as something other than HTTP, or something built over HTTP with restricted semantics (i.e. predicablt requests). It relies on present implementations rather than the HTTP specification. There's no way an implementation could even know that the response had been sent before reading the request, unless of course it was a response for a different request (which is the fundamental issue with the technique), so I find the author's amazement that it works itself rather amazing. – user207421 Jun 09 '14 at 23:50