Re: RFR: 8273655: content-types.properties files are missing some common types

On Tue, 14 Sep 2021 09:46:21 GMT, Julia Boes wrote: > This change adds some common types to the content-type.properties files, > notably .js, .css, and .jar, as well as some others. > > The duplicated entry for .zip is removed from the Windows properties file.

Re: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system

Hi Julia On 06/03/2020 14:04, Julia Boes wrote: Hi Anthony, Thanks for your comments. For distinguishing the non-default filesystem case, an alternative to using the try-catch block is an if-else block with the same check as is done in Path::toFile:     if (path.getFileSystem() ==

Re: HTTP client API

Hi Tobias As far as I know, the latest published Javadoc is at [1] (which was linked to in [2]). However, this Javadoc doesn't exactly match the current code either. Below are some quick replies to some of your feedback. 1.) > What is the advantage of the Publisher / Subscriber API over

Re: HTTP client API

Hi Michael What's the rationale for not turning all public classes into interfaces, since none of them contain any actual implementation code? On another note, I fail to see the point of HttpClient.Builder::priority: as far as I understand, HTTP/2 priority only comes into play when multiple

JEP 110: leeway for API changes?

Hi With the JDK's "Feature Complete" milestone coming up next week: how much leeway is there still for API changes? I've made API suggestions (a.o. in [1]), ranging from changing HttpResponse.multiProcessor::onStart's return type (from BiFunction<..., Boolean> to BiPredicate), to building on

Re: RFR JDK-8087113: Websocket API and implementation

Hi Pavel Thanks for your considerate response, replies are inline. On 4/04/2016 13:08, Pavel Rappo wrote: Hi Anthony, thanks a lot for looking into this! On 3 Apr 2016, at 17:45, Anthony Vanelverdinghe <anthony.vanelverdin...@gmail.com> wrote: Here are my suggestions concerning the

Re: RFR JDK-8087113: Websocket API and implementation

Hi Pavel Here are my suggestions concerning the public types: java.net.http.WebSocket - order the arguments of static Builder newBuilder(URI uri, HttpClient client, Listener listener) consistently with the 2-argument method: static Builder newBuilder(URI uri, Listener listener, HttpClient

Re: RFR: 8087112 HTTP API and HTTP/1.1 implementation

eceiving side, I like the use of Optional there and what you're suggesting is concise and quite similar to what is there functionally. In fact we did look at this option before. But, extending Flow.Subscriber means you would not be able to leverage existing Subscriber implementations directly and

Re: RFR: 8087112 HTTP API and HTTP/1.1 implementation

Hi Michael Here's my feedback. If that'd be helpful, I'm willing to contribute patches to address these points. Either way, please let me know if you have any questions. Some general proposals: First, MultiExchange implements a retry mechanism. However, I see some issues with this: - it's

Re: RFR: 8087112: HTTP API and HTTP/1.1 implementation

0x7c) || (c == 0x7e); } PS: I have signed the OCA [2], so you can reuse any code if you wish [1] http://cr.openjdk.java.net/~michaelm/8087112/01/src/java.base/share/classes/sun/net/httpclient/Utils.java.html [2] http://www.oracle.com/technetwork/community/oca-486395.html#v Kind regar

Re: RFR: 8087112: HTTP API and HTTP/1.1 implementation

Hi Michael Maybe these have been fixed in the meantime, but I think I've found a bug: in http://cr.openjdk.java.net/~michaelm/8087112/01/src/java.base/share/classes/sun/net/httpclient/Utils.java.html single quotes must be accepted, while parentheses must be rejected [1] and a few typos: in

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

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

Re: Problem with fix B6369510 for HttpURLConnection Content-Type

Hello I don't see any issues with the bug, fix, and test: before the bug, the header was set for all but PUT requests (cfr. the evaluation) then it was reported this should not be done for GET requests, and the evaluation agreed on this, so the test makes sure GET requests don't have this

Re: Http client API

installer ( http://javafx-jira.kenai.com/browse/RT-21275 ). The solution to this JavaFX issue says the fix enhanced code to follow https redirects. So JavaFX seems to already implement this feature. Thanks for your feedback Anthony Vanelverdinghe Op 8/08/2012 1:09, Michael McMahon schreef: Hi