Re: RFR 8163561, add a test for Proxy Authentication in HTTP/2 Client API

> On 19 Aug 2016, at 10:38, Felix Yang wrote: > > Hi Chris, > >thanks for the comments. Updated webrev: > > http://cr.openjdk.java.net/~xiaofeya/8163561/webrev.01/ > Looks good. Thanks Felix. -Chris. > > Thanks, > Felix > On 20

Re: RFR 8163561, add a test for Proxy Authentication in HTTP/2 Client API

Hi Chris, thanks for the comments. Updated webrev: http://cr.openjdk.java.net/~xiaofeya/8163561/webrev.01/ Thanks, Felix On 2016/8/18 23:43, Chris Hegarty wrote: On 18 Aug 2016, at 10:26, Felix Yang wrote: Hi all, please review a new test, which tries to verify "Proxy-Authenticate"

Re: RFR 8163561, add a test for Proxy Authentication in HTTP/2 Client API

On 18 Aug 2016, at 10:26, Felix Yang wrote: > > Hi all, > >please review a new test, which tries to verify "Proxy-Authenticate" > header can be handled correctly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163561 > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8163561/webrev.00/

RFR 8163561, add a test for Proxy Authentication in HTTP/2 Client API

Hi all, please review a new test, which tries to verify "Proxy-Authenticate" header can be handled correctly. Bug: https://bugs.openjdk.java.net/browse/JDK-8163561 Webrev: http://cr.openjdk.java.net/~xiaofeya/8163561/webrev.00/ Thanks, Felix

Re: HTTP 2 client API

By NIO2, I meant the following style of flow-control (back-pressure), in pseudo code: channel.notifywhenreadable(callback) // edge trigger ideally channel.notifywhenwritable(callback) int channel.availablebytes(); int channel.read(int, buf);// always from callback int channel.write(buf);

Re: HTTP 2 client API

Actually, thinking about this again. There is an obviously better way of notifying request completion, by just de-coupling the send and the receive explicitly, while still keeping a way to do both together. 1. 2. and 3. below would be replaced with the following: (HttpRequest) void send() -> blo

Re: HTTP 2 client API

Here is what I propose on some of the issues you raised yesterday: 1. make it clear that HttpRequest.send() blocks until entire request is sent and the response headers received. 2. Add a new method to HttpRequest /** * Notifies when this request has been completely sent. If the re

Re: HTTP 2 client API

Wenbo, On WebSockets, that API work is being handled separately to this work and will be put out for review very soon. - Michael On 31/07/15 19:37, Wenbo Zhu wrote: On Fri, Jul 31, 2015 at 11:32 AM, Simone Bordet mailto:simone.bor...@gmail.com>> wrote: Hi, On Fri, Jul 31, 2015 a

Re: HTTP 2 client API

Hi, On Fri, Jul 31, 2015 at 8:37 PM, Wenbo Zhu wrote: >> > Or we follow the NIO2 model (readiness), >> >> Please no ! :) > > Ignoring the epoll part, is the issue in the API styles or the actual model? https://webtide.com/on-jdk-7-asynchronous-io/ and http://www.slideshare.net/SimoneBordet/ser

Re: HTTP 2 client API

On Fri, Jul 31, 2015 at 11:32 AM, Simone Bordet wrote: > Hi, > > On Fri, Jul 31, 2015 at 7:54 PM, Wenbo Zhu wrote: > > Thanks for the update. > > > > === > > > > Is WebSocket out of the scope now? > > > > == async streams > > > > I.e. how bodies are to be read/written asynchronously, with flow-c

Re: HTTP 2 client API

Hi, On Fri, Jul 31, 2015 at 7:54 PM, Wenbo Zhu wrote: > Thanks for the update. > > === > > Is WebSocket out of the scope now? > > == async streams > > I.e. how bodies are to be read/written asynchronously, with flow-control > (aka back pressures). > > There are many different styles or abstractio

Re: HTTP 2 client API

Hi, On Fri, Jul 31, 2015 at 6:33 PM, Michael McMahon wrote: > Well, it needs co-operation between the producer and the consumer > obviously. But, the onResponseBodyChunk() method could write to a queue > and block if it reaches a certain size. The onRequestBodyChunk() would > read off the data an

Re: HTTP 2 client API

On 31/07/15 16:06, Simone Bordet wrote: Hi, On Fri, Jul 31, 2015 at 3:56 PM, Michael McMahon wrote: Ok. Now, on the whole flow-control issue, here is my thinking. First that isFast() method is a relic from a previous version and should not have been there. My thinking is that the body process

Re: HTTP 2 client API

Hi, On Fri, Jul 31, 2015 at 4:19 PM, Michael McMahon wrote: > Sorry, just on that point again. It was never intended to support > anything other than URIs here, whether as a String or URI object. > We don't want to allow CONNECTs directly and since it is possible > to create a request without a U

Re: HTTP 2 client API

Hi, On Fri, Jul 31, 2015 at 3:56 PM, Michael McMahon wrote: > Ok. Now, on the whole flow-control issue, here is my thinking. > First that isFast() method is a relic from a previous version and should not > have been there. > > My thinking is that the body processing methods of the response > body

Re: HTTP 2 client API

On 31/07/15 14:56, Michael McMahon wrote: T == HttpRequest.create(URI) and related. Using a URI is not correct since requests may be made for targets that are not URIs, see https://tools.ietf.org/html/rfc7230#section-5.3. Examples: OPTIONS * HTTP/1.1, CONNECT foo:9090 HTTP/1.1 where "*" and "fo

Re: HTTP 2 client API

Thanks for the quick review, Simone. Some answers below. Michael On 31/07/15 14:10, Simone Bordet wrote: Hi, On Fri, Jul 31, 2015 at 9:00 AM, Michael McMahon wrote: Hi Wenbo, The latest version of the docs is available at: http://cr.openjdk.java.net/~michaelm/8087112/2/ I am hoping to final

Re: HTTP 2 client API

Hi, On Fri, Jul 31, 2015 at 9:00 AM, Michael McMahon wrote: > Hi Wenbo, > > The latest version of the docs is available at: > http://cr.openjdk.java.net/~michaelm/8087112/2/ > I am hoping to finalize this very soon. Comments below. == HttpRequest.create(URI) and related. Using a URI is not corr

Re: HTTP 2 client API

Hi Wenbo, The latest version of the docs is available at: http://cr.openjdk.java.net/~michaelm/8087112/2/ I am hoping to finalize this very soon. Thanks, Michael. On 31/07/15 00:26, Wenbo Zhu wrote: Has the API docs been moved? Is there an updated version of it? Thanks, Wenbo On Mon, Mar 9,

Re: HTTP 2 client API

Hi Michael Further feedback is in-line (please note that, to improve readability, I took the liberty to discard points without further feedback). On 25/03/2015 18:33, Michael McMahon wrote: * how is compression (the Accept-Encoding/Content-Encoding/Transfer-Encoding headers) handled? Is this

Re: HTTP 2 client API

Hi Anthony, Comments/answers below On 21/03/15 10:44, Anthony Vanelverdinghe wrote: Hi Michael Please find my feedback on the current API docs below. It's divided in 3 parts: API (mostly questions), documentation (mostly suggestions for clarifications) and spelling. Thanks in advance for y

Re: HTTP 2 client API

Hi Michael Please find my feedback on the current API docs below. It's divided in 3 parts: API (mostly questions), documentation (mostly suggestions for clarifications) and spelling. Thanks in advance for your consideration. Kind regards, Anthony === API === * will there be support for HTTP

HTTP 2 client API

Hi, JEP 110 HTTP 2 client in JDK 9, is defining and implementing a new API for HTTP which also supports the new HTTP version 2 that has recently been working its way through the IETF. The work also includes support for websockets (RFC 6455). In fact, the majority of the API is agnostic about