Question about com.sun.net.httpserver.HttpExchange#sendResponseHeaders

[Wenbo Zhu]

Per the HTTP spec, chunked encoding may not be needed if "Connection:
close" is set and the TCP connection will be closed (FIN) to complete the
response body.

I am yet to write a test for this but the javadoc needs to address this
behavior..

This behavior can be supported using the existing API, e.g. by asking the
application to add the Connection header before #sendResponseHeaders is
called.

===

I am adding com.sun.net.httpserver. as a lightweight http/1 server runtime
for a framework. The (low-level) com.sun.net APIs are very well documented.
Thanks for your work on this library.

- Wenbo

Re: HTTP client API

[Wenbo Zhu]

On Mon, Aug 22, 2016 at 12:56 AM, Michael McMahon <
michael.x.mcma...@oracle.com> wrote:

> There is an updated version of the HTTP client API doc [1] and a specdiff
> [2] showing the changes
> proposed from the current version in JDK9 dev.
>
> The main changes are:
>
> 1) The request and response processors are now based on Flow.Publisher and
> Flow.Subscriber
>
> 2) Response bodies are retrieved synchronously with the response headers
> as part of the
> HttpRequest.response() and responseAsync() methods
>
> 3) Because of the change above, to allow code to examine the headers and
> decide what to do
> with the body before retrieving it, there is a new entity called a
> HttpResponse.BodyHandler
> which is given the status code and headers, and which returns a
> HttpResponse.BodyProcessor.
> Static implementations of both body handlers and body processors are
> provided, to make the
> simple cases easy to code.
>
> We are currently working in the sandbox repository again and will have
> these changes
> in the main JDK9 dev forest soon.
>
Is it possible to access the API code somewhere before then, mainly as a
convenience for reviewing the APIs?



>
> Thanks,
>
> Michael
>
> [1] http://cr.openjdk.java.net/~michaelm/httpclient/api/
>
> [2] http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout/
> package-summary.html
>
>

Re: HTTP 2 client API

[Wenbo Zhu]

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);// always from callback

HTTP always assumes a byte-stream transport (even over UDP), and the above
flow-control style is easy to understand and maps well to the underlying
OS/transport.

There could be other variants to the above style, but if "Flow" is the
future, then there is no point to invent another style IMO.

- Wenbo


On Fri, Jul 31, 2015 at 11:52 AM, Simone Bordet 
wrote:

> 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/servlet-31-async-io, from slide
> 22 onwards.
>
> NIO2 is not an API I would like to see replicated/used in HttpClient.
>
> I know of people that are already upset with the current API because
> it forces too much allocation.
> That's because of the API, not because of the implementation.
>
> Now, perhaps these people are at one extreme of the spectrum, but
> certainly it is something we want to care about for an official JDK
> API.
> For example, the current API forces the allocation of a URI object for
> every request. That may be saved by changing the API (or supporting an
> overloaded version that takes a String).
>
> Me, I'd like to get the semantic right first, and then look at
> opportunities for improving performance.
>
> --
> Simone Bordet
> http://bordet.blogspot.com
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz
>

Re: HTTP 2 client API

[Wenbo Zhu]

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-control
> > (aka back pressures).
> >
> > There are many different styles or abstractions. IMO, if reactive streams
> > are to be included in jdk9, we may want to adopt the same model (if not
> the
> > API).
>
> Okay.
>
> > Or we follow the NIO2 model (readiness),
>
> Please no ! :)
>
Ignoring the epoll part, is the issue in the API styles or the actual
model?


> > to not introduce another concept.
>
> Reactive streams and NIO2 are at 2 different levels of abstraction.
> If it's not reactive streams, then it must be something new.
>
> FWIW, we're discussing with the Servlet 4 EG about introducing a
> reactive stream API for Servlet 4 async I/O.
> Not yet carved in stone, but it's getting a little traction.
>
Ah, I just cross-post this thread to the EG mailing list.



>
> --
> Simone Bordet
> http://bordet.blogspot.com
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz
>

Re: JEP 110: HTTP 2 Client

[Wenbo Zhu]

I am new to the JEP process. Has there been any update on this work? Is
there an API proposal to look at?

Thanks,
Wenbo


> JEP 110: HTTP 2 Client*mark.reinhold at oracle.com * 
> mark.reinhold
> at oracle.com
> 
> *Wed Nov 12 22:59:55 UTC 2014*
>
>
>- Previous message: RFR: JDK-8015692 - java.net.BindException is
>thrown on Windows XP when HTTP server is started and stopped in the loop.
>
>- Next message: RFR: JDK-8065222 -
>sun/net/www/protocol/http/B6369510.java doesn't execute as expected
>
>- *Messages sorted by:* [ date ]
>
> 
> [ thread ]
>
> 
> [ subject ]
>
> 
> [ author ]
>
> 
>
> --
>
> New JEP Candidate: http://openjdk.java.net/jeps/110
>
> - Mark
>
>