RFR: 8087112 HTTP API and HTTP/1.1 implementation

[Michael McMahon]

On 18/02/16 16:06, Paul Sandoz wrote:
>> On 18 Feb 2016, at 16:37, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
>>
>>> When building a request how does one set multiple values for a header? setHeaders overwrites, does one used headers(…) instead?
>>>
>> headers(String, String)
>> and headers(String ...) both accumulate headers
>>
> What headers would be included in the request for the following expressions:
>
> -  setHeader(“foo”, “value1”).setHeaders(“foo”, “value2”)

Foo: value2
> -  headers(“foo”, “value2”).headers(“foo”, “value2”)

Foo: value2
Foo: value2

> Or put another way if i want my request to contain the header lines:
>
>    Foo: value1
>    Foo: value2
>
> how can i express that in the API?
>
>
>>> Processors
>>> —
>>>
>>> I think the flowController of HttpRequest.BodyProcessor.onRequestStart requires more specification (a follow up issue if you wish):
>>> - what are the units? It represents unfulfilled demand, but of what?
>>> - what if a -ve value is passed
>>> - what if Long.MAX_VALUE is passed? effectively unbounded?
>>> - does it have to be called within onRequestStart and onRequestBodyChunk?
>>> - what happens if it is invoked outside the life-cycle of a BodyProcessor?
>>>
>> yes, spec that is in HttpResponse.BodyProcessor applies here too,
>> but it should be repeated.
>>
> Ok.
>
>
>>> OK, i see there is more specification in HttpResponse.BodyProcessor. I wonder how implementations correlate the unit to bytes? Is there any correlation related to an internal buffer size? Why would the requested unfulfilled demand be greater than 1? i.e. as an implementor of a body processor how am i meant to correlate the bytes i read/write to the units required to express the unfulfilled demand?
>>>
>> There is no direct correlation between units and bytes. If the window size is 1, then the processor
>> is willing to accept one more call, of whatever sized ByteBuffer.
>>
>> The implementor of the processor must then decide based on how long it takes to consume the
>> data whether to update the window immediately or to delay and update it later.
>>
> Sorry, still don’t get why a value greater than 1 needs to be provided. If i pass in 1 and may get one or more calls, then why pass in 1? Why not use a Runnable instead?
>

In practice, 1 seems to be the most likely use-case, but a value of N means
that N further calls to provide 1 ByteBuffer is permitted.

It's exactly the same with the Flow API.

>>> For responses, what happens if the Consumer<Buffer> is called outside the life-cycle of the processors?
>>>
>> Actually, that is not part of the current API. For the moment, the life-cycle of the ByteBuffer is
>> that it only belongs to the processor for the duration of the call, meaning it would have to be
>> copied if the data isn't consumed fully during the call.
>>
> But happens if the Consumer is invoked outside of the life-cycle of the response, should an ISE be thrown?
>
> Same for the LongConsumer, what happens if it is invoked outside the life-cycle of the request or response.

There is no Consumer<> but for the LongConsumer, it's not specified. I 
would expect it just to have
no effect.

Michael