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

[Wenbo Zhu]

Thanks! The text looks good.

p.s. is there a way I could get notified of any future updates on this
issue? I had thought that I have a java.net account ...



On Wed, Feb 6, 2019 at 4:26 AM Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Hi Wenbo,
>
> This looks like a reasonable request.
> Since we are in agreement on the spec, I have logged
> https://bugs.openjdk.java.net/browse/JDK-8218554
> to track it.
> The issue has a link to this mail thread for reference.
>
> best regards,
>
> -- daniel
>
> On 02/02/2019 00:27, Wenbo Zhu wrote:
> >
> >
> > On Fri, Feb 1, 2019 at 2:58 PM Daniel Fuchs <daniel.fuchs at oracle.com
> > <mailto:daniel.fuchs at oracle.com>> wrote:
> >
> >     Hi Wembo,
> >
> >     On 01/02/19 19:50, Wenbo Zhu wrote:
> >      > 1) clarify in the API javadoc that chunked encoding is always
> >     applied
> >      > even with Connection: close
> >
> >     Chunked encoding is always applied if 0 is passed to
> >     sendResponseHeaders (this is a bit counter-intuitive, but
> >     0 means chunked coding and -1 means Content-Length: 0 or
> >     no content - depending on response code, and n > 0 means
> >     Content-Length: n).
> >
> > Yeah, it could be better ... but I can live with this, 0 meaning
> > "content-length unknown when response headers are generated".
> >
> >     Whether chunked coding is applied or not bears no relationship
> >     with Connection: close whatsoever.
> >
> >     On the client side - if we have 200 with no Content-Length
> >     header and no Transfer-Encoding then we don't expect the
> >     content to be chunked. We simply drain the bytes until
> >     EOF is reached.
> >
> >     Is this what you mean by always applied?
> >
> > Yes.
> >
> >
> >     best regards,
> >
> >     -- daniel
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190206/4f45fa3a/attachment.html>