gmane.comp.java.openjdk.net.devel

Beware of Biggest Fake conference in computer science

2013-05-21T21:12:06

Beware of Biggest Fake conference in computer science

If you have any plans of participating in the world’s biggest 
fake computer science conference then you must look at the website https://sites.google.com/site/worlddump1

If the above link didn't work then see

http://worldcomp-fake-bogus.blogspot.com  
or
https://sites.google.com/site/dumpconf
or Google search using keywords: worldcomp, fake

Re: 8010464 (was Re: RFR: 8012261: update policytool to supportjava.net.HttpURLPermission)

Chris Hegarty — 2013-05-17T10:24:13

D'oh. I missed this in the review. I think it should be using 
sun.net.util.URLUtil.urlNoFragString(URL)

-Chris

8010464 (was Re: RFR: 8012261: update policytool to supportjava.net.HttpURLPermission)

Weijun Wang — 2013-05-17T10:07:47


On 5/17/13 5:50 PM, Tom Hawtin wrote:

I think this comment is on Michael's (already-pushed) changeset above.

-Max

Re: RFR: 8012261: update policytool to supportjava.net.HttpURLPermission

Tom Hawtin — 2013-05-17T09:50:17


Not looked through it thoroughly, but are we sure we want url.toString()?

Tom

Re: Non-standard socket options?

Alan Bateman — 2013-05-16T11:44:30

Thanks for checking, I suspected this was the case.

We've created two bugs to track this (one for DatagramChannel, one for 
legacy MulticastSocket). You can find them here (including a link to a 
prototype and test case):

http://bugs.sun.com/view_bug.do?bug_id=8014377

http://bugs.sun.com/view_bug.do?bug_id=8014499

-Alan

Re: Incorrect handling of HTTP/1.1 "Expect: 100-continue" inHttpURLConnection

Michael McMahon — 2013-05-16T08:54:07

Probably doesn't need to be othervm, as it is cleaning up already. The 
test was written quickly, hence
the static/instance field confusion. That can be changed easily too.

Thanks
Michael

Re: Code Review Request: 7150552: network test hangs [macosx]

Chris Hegarty — 2013-05-16T08:51:29

What you have looks fine.

Thanks for liberating CookieManagerTest, and for removing another 
dependency on test/sun/net/www/httptest.

-Chris.

On 05/15/2013 11:18 PM, Kurchi Hazra wrote:

Code Review Request: 7150552: network test hangs [macosx]

Kurchi Hazra — 2013-05-15T22:18:22


Hi,

Two regression tests in jdk/test were hanging on Mac OS X 
intermittently. Although it is difficult to reproduce
the problem, I suspect it is the use of the buggy httpserver test 
library (jdk/test/sun/net/www/httptest) - we anyway want
to move away from using it. I have re-written parts of these tests to 
use com.sun.net.httpserver instead.

I have also unleashed the tests from the ProblemList and will keep a 
closer watch on test runs.

Bug: http://bugs.sun.com/view_bug.do?bug_id=7150552
Webrev: http://cr.openjdk.java.net/~khazra/7150552/webrev.00/


Thanks!
Kurchi

Re: Non-standard socket options?

Brian Call — 2013-05-15T21:28:06

I just asked Neil if that option was supported for ipv6 and he said that he doesn't think so... Likely once adoption of ipv6 reaches critical mass and enough people complain, it will be added. We can only hope... 

Please let me know if I can be of any more assistance. 

-Brian 

On May 11, 2013, at 8:42 AM, Alan Bateman <Alan.Bateman-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org> wrote:


Blessings,

Brian Call
brian.call-MIrZLZ0+oP3Wpu6QEFMNjNBPR1lH4CV8< at >public.gmane.org

PRIVILEGED AND CONFIDENTIAL COMMUNICATION: This electronic transmission, and any documents attached hereto, may contain confidential and/or legally privileged information.  The information is intended only for use by the recipient named above. If you have received this electronic message in error, please notify the sender and delete the electronic message. Any disclosure, copying, distribution, or use of the contents of information received in error is strictly prohibited.

Re: Incorrect handling of HTTP/1.1 "Expect: 100-continue" inHttpURLConnection

Piotr Bzdyl — 2013-05-15T20:16:26

Thank you again for taking time to look at the issue. The proposed fix will
eliminate the surprise we encountered as there will be no delay when Expect
header and no streaming is used.

Best regards,
Piotr


On Wed, May 15, 2013 at 6:33 PM, Michael McMahon <
michael.x.mcmahon-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org> wrote:

Re: Incorrect handling of HTTP/1.1 "Expect: 100-continue" inHttpURLConnection

Alan Bateman — 2013-05-15T18:22:12

The fix looks okay to me too.

For the test then is there any reason that is has to run in othervm 
mode? Just wondering if you could shutdown the http server when done. 
Also not clear why the fields are static when they are initialized in 
the ctor. Alignment issue at L93.

-Alan.

Re: Incorrect handling of HTTP/1.1 "Expect: 100-continue" inHttpURLConnection

Chris Hegarty — 2013-05-15T17:09:49

The change looks fine to me.

-Chris

On 15 May 2013, at 17:33, Michael McMahon <michael.x.mcmahon-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org> wrote:

Re: Incorrect handling of HTTP/1.1 "Expect: 100-continue" inHttpURLConnection

Michael McMahon — 2013-05-15T16:33:04

This is the webrev for the bug

http://cr.openjdk.java.net/~michaelm/8012625/webrev.1/

Thanks
Michael

On 15/05/13 17:03, Michael McMahon wrote:

Re: Incorrect handling of HTTP/1.1 "Expect: 100-continue" inHttpURLConnection

Michael McMahon — 2013-05-15T16:03:48

Piotr,

We took a look at this issue again, and while it is still the case that 
to get Expect: Continue
to work properly, you need to enable one of the streaming modes. 
However, prior to jdk7
there was partial support for this mechanism, where it obeyed the 
protocol at least
when you set the Expect header. What it didn't do is delay sending the 
request body until
the 100 response is received. However, that might not have been a 
problem in many cases,
and it looks like in jdk7 this specific mode is not working exactly the 
same as before. One problem
is that a 5 second delay can be seen.

Anyhow, we will fix the problem in jdk 8 so that the exact same behavior 
as jdk 6 is seen.
I'll send a webrev with a fix soon.

Thanks
Michael

On 07/05/13 15:40, Piotr Bzdyl wrote:

Re: RFR JDK7188517

Chris Hegarty — 2013-05-15T12:23:31

Sorry about the noise on the list, this mail was intended for John only. 
But the point still stands.

-Chris.

[OFFLIST] Re: RFR JDK7188517

Chris Hegarty — 2013-05-15T12:02:49

[OFFLIST]

I believe the reviews on the open list are complete. The CCC has been 
accepted, nut it needs to be make final, then the CCC committee need to 
vote again.

I did send mail to you about making it final ( one step process ), but 
you may not have seen it.

-Chris.

On 15/05/2013 12:54, John Zavgren wrote:

Re: RFR JDK7188517

John Zavgren — 2013-05-15T11:54:01

Greetings:

Can I get a show of hands on this RFR 
(http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/)?
It's CCC request has been accepted and I'd like to wrap it up ASAP.

Thanks!
John Zavgren

On 05/09/2013 02:22 PM, John Zavgren wrote:

Re: Code review: 8010464: Evolve java networking same origin policy

Alan Bateman — 2013-05-15T11:53:11

This looks much better.

In HttpURLConnection then odd formatting in the declaration of 
followRedirect0 (which probably needs a better name, maybe 
implFollowRedirect?) A couple of indentation issues that probably should 
be fixed too, L980 and L2951  for example.

I don't see any other issues.

-Alan

Re: Code review: 8010464: Evolve java networking same origin policy

Michael McMahon — 2013-05-15T11:46:51

...

updated here:

http://cr.openjdk.java.net/~michaelm/8010464/webrev.3/

Michael.

Re: Code review: 8010464: Evolve java networking same origin policy

Michael McMahon — 2013-05-15T11:12:59

well spotted and that's a simpler way of doing it. I messed the change 
up from the previous revision.
It's unfortunate the actual end to end HttpURLConnection tests only use 
one header in each
request. So, they didn't catch that. I'll update the test as well.

Thanks
Michael

Re: Code review: 8010464: Evolve java networking same origin policy

Alan Bateman — 2013-05-15T11:02:20

I think getHeaderNamesInList needs to be checked anyway as it looks to 
me that it just appends the keys and will never insert a comma.

The only reason I suggested StringJoiner here is because I thought this 
method was trying to do this:

StringJoiner joiner = new StringJoiner(",");
for (int i=0; i<nkeys; i++) {
     joiner.add(keys[i]);
}
return joiner.toString();

Okay.