On Sun, 15 Jul 2018, at 9:58 PM, Oleg Kalnichevski wrote:
> On Sun, 2018-07-15 at 21:41 +1000, Alex Osborne wrote:
> > Here's a simplified example of what I want to do. I want to make two
> > requests each having its own directory and save all the corresponding
> > responses (both the main response and any push responses) to the
> > appropriate directory.
> > 
> > client.register("*", () -> new
> > FileSavingDataConsumer("/tmp/request??/")));
> > client.execute(request1, new
> > FileSavingDataConsumer("/tmp/request1/"), null);
> > client.execute(request2,  new
> > FileSavingDataConsumer("/tmp/request2/"), null);
> > 
> Given the example you can clearly use the original request request URI
> as a correlation id. 

Sorry if I'm missing something obvious. I still don't see how to do it. :-(

Say request1 is for GET /page1.html and for that page the server pushes GET 
/cat.jpg.
Say request2 is for GET /page2.html and for that page the server pushes GET 
/dog.jpg.

I'm sending the requests to an arbitrary server I have no control over and I 
don't know in advance which resources its going push so I can't 
client.register("/cat.jpg") specifcially.

The Supplier<AsyncPushConsumer> register receives no arguments when it's called 
so it doesn't know the appropriate original request URI.
The AsyncPushConsumer it returns receives:

HttpRequest[GET /cat.jpg], HttpResponse[200 image/jpeg]
HttpRequest[GET /dog.jpg], HttpResponse[200 image/jpeg]

So there's still no association with the original request URIs /page1.html and 
/page2.html.

> I am sure it is possible. Please do refer me to a section of the
> specification that states _how_ _exactly_ those messages are associated
> other than through the promised request that server pushes to the
> client.

Expacing the quote from section 8.2.1:

   Pushed responses are always associated with an explicit request from
   the client.  The PUSH_PROMISE frames sent by the server are sent on
   that explicit request's stream.  The PUSH_PROMISE frame also includes
   a promised stream identifier, chosen from the stream identifiers
   available to the server

The PUSH_PROMISE frame is what associates them. It's sent on the stream the 
client sent the original request on and includes the id of a new stream the 
pushed response will be sent on.

[stream 1] Client: GET /page1.html, END_STREAM (half-closes)
[stream 3] Client: GET /page2.html, END_STREAM (half-closes)
[stream 1] Server: PUSH_PROMISE /cat.jpg promising stream 2
[stream 3] Server: PUSH_PROMISE /dog.jpg promising stream 4

Then interleaved:
[stream 1] Server: the response HEADERS, DATA for page1.html
[stream 2] Server: the response HEADERS, DATA for cat.jpg
[stream 3] Server: the response HEADERS, DATA for page2.html
[stream 4] Server: the response HEADERS, DATA for dog.jpg

> We happily take patches. Will be more than happy to commit a change-set 
> that makes correlation of push response messages easier.

Thanks. I'll attempt to do so and send a patch if I get it working. :-)

Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Reply via email to