> 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”) - headers(“foo”, “value2”).headers(“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? >> 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. Paul.
signature.asc
Description: Message signed with OpenPGP using GPGMail
