On 18/02/16 16:06, Paul Sandoz wrote:
On 18 Feb 2016, at 16:37, Michael McMahon <michael.x.mcma...@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
