/~arieber/6563286/webrev.00/test/sun/net/www/http/HttpURLConnection/MalformedFollowRedirect.java.html
http://cr.openjdk.java.net/%7Earieber/6563286/webrev.00/test/sun/net/www/http/HttpURLConnection/MalformedFollowRedirect.java.html
On 6/26/2013 10:54 AM, John Zavgren wrote:
Please consider
Greetings:
Please consider the following socket constructor changes:
http://cr.openjdk.java.net/~jzavgren/8017079/webrev.01/
http://cr.openjdk.java.net/%7Ejzavgren/8017079/webrev.01/
Thanks!
John
--
John Zavgren
john.zavg...@oracle.com
603-821-0904
US-Burlington-MA
--
John Zavgren
john.zavg...@oracle.com
603-821-0904
US-Burlington-MA
{
@Override
public MapString, ListString get(URI uri, MapString,
ListString requestHeaders) {
return new HashMapString, ListString();
}
@Override
public void put(URI uri, MapString, ListString responseHeaders) {
}
}
-
-Chris.
On 06/19/2013 04:27 PM, John Zavgren
Greetings:
Please review the following changes for a bug that's caused by empty
cookie header strings. The proposed change detects this condition and
returns early.
http://cr.openjdk.java.net/~jzavgren/8015799/webrev.01/
http://cr.openjdk.java.net/%7Ejzavgren/8015799/webrev.01/
--
John
/~jzavgren/8014499/webrev.04/
http://cr.openjdk.java.net/%7Ejzavgren/8014499/webrev.04/
Thanks!
--
John Zavgren
john.zavg...@oracle.com
603-821-0904
US-Burlington-MA
://cr.openjdk.java.net/~jzavgren/8014377/webrev.03/
http://cr.openjdk.java.net/%7Ejzavgren/8014377/webrev.03/
Thanks!
--
John Zavgren
john.zavg...@oracle.com
603-821-0904
US-Burlington-MA
*/
if (setsockopt(fd, SOL_SOCKET, SO_BROADCAST, (char*) t,
sizeof(int))0) {
JNU_ThrowByName(env, JNU_JAVANETPKG SocketException,
Unable to set SO_BROADCAST);
return; setsockopt() failed, we threw an exception. We
didn't close the socket.
}
--
John Zavgren
All:
I'd like to give everyone another chance to weigh in on this change:
http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/
so that I can wrap up this fix ASAP.
(It makes HTTP cookies that begin with a dollar sign illegal.)
Thanks!
John
On 05/15/2013 07:54 AM, John Zavgren wrote
All:
I have a revised webrev image that's ready for review:
http://cr.openjdk.java.net/~jzavgren/8008972/webrev.04/
Thanks
John
On 05/13/2013 04:14 PM, John Zavgren wrote:
Greetings:
I posted a new webrev image:
http://cr.openjdk.java.net/~jzavgren/8008972/webrev.03/
that fixes a memory leak
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:
Greetings:
I made a mistake in my last RFR posting
files in the same directory as the two previously mentioned files.
On 03/04/2013 01:17 PM, Chris Hegarty wrote:
On 03/04/2013 04:28 PM, John Zavgren wrote:
Greetings:
I've posted a webrev image of a memory leak fix:
http://cr.openjdk.java.net/~jzavgren/8008972/webrev.01/
Sorry John, I don't
if the IllegalArgumentException is not
obtained, otherwise the test looses its
purpose, and will pass silently if someone mistakenly removes the $
check in our code.
- Kurchi
On 5/8/2013 12:10 PM, John Zavgren wrote:
Greetings:
I added a test for the leading dollar sign character in cookie
for cookie
names that lead with a dollar sign.
I'm sorry about the confusion.
Thanks!
John
On 05/09/2013 03:42 PM, John Zavgren wrote:
Chris, et alia:
I put the reinstated the old test.
http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/
John
- Original Message -
From: chris.hega
On 5/2/2013 10:09 AM, John Zavgren wrote:
All:
My original email was mangled by my email program (stbeehive/zimbra)
... so I'm sending a second correctly formatted copy.
I'm sorry for the inconvenience.
John
---
Please consider the following change to the cookie constructor:
http
SO_BINDTODEVICE can be used in cases where an IP network application doesn't
want the existing routing table entries to determine the interface that packets
are transmitted from. This is often the case when one is writing a router that
needs to do neighbor discovery. I used this extensively a
is not necessary.
Thanks!
John Zavgren
:
http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ ) prohibited the use of
cookie names that are one of the tokens reserved for use by the cookie
protocol, and this restriction is not necessary.
Thanks!
John Zavgren
- Original Message -
From: john.zavg...@oracle.com
To: net
Greetings:
I've cleaned up some formatting nits and a leak that I created in my
realloc() repairs and created a revised webrev image:
http://cr.openjdk.java.net/~jzavgren/8012108/webrev.04
John
On 04/24/2013 09:10 PM, John Zavgren wrote:
All:
I expanded the scope of the work
01:33, John Zavgren wrote:
Greetings:
I fixed the bad realloc pattern. Please let me know what you think.
http://cr.openjdk.java.net/~jzavgren/8012108/webrev.02/
Thanks!
John Z
- Original Message -
From: chris.hega...@oracle.com
To: net-dev@openjdk.java.net, john.zavg...@oracle.com
Cc
wrote:
John,
102, 145 else is redundant.
438 - we will crash here if start is null
Maybe it is good to have an additional check for start != null, but from what I
see, start will not be null if *netaddrPP is not null.
-Dmitry
On 2013-04-20 01:33, John Zavgren wrote:
Greetings:
I
= (IP_ADAPTER_ADDRESSES *) realloc (adapterInfo, len);
-Dmitry
On 2013-04-19 00:56, John Zavgren wrote:
Greetings:
I fixed a case in the windows native code where calloc() was being used
without checking it's returned value.
http://cr.openjdk.java.net/~jzavgren/8012108/webrev.01/
Thanks
Greetings:
I fixed a case in the windows native code where calloc() was being used without
checking it's returned value.
http://cr.openjdk.java.net/~jzavgren/8012108/webrev.01/
Thanks!
John Zavgren
Greetings:
Please review the following webrev image. I fixed a memory leak that can occur
when calloc() fails.
http://cr.openjdk.java.net/~jzavgren/8012108/webrev.01/
Thanks!
John Zavgren
john.zavg...@oracle.com
://www.ietf.org/rfc/rfc2617.txt) section 3.2.2
and follow its references back to section 3.2.1
http://cr.openjdk.java.net/~jzavgren/8010505/webrev.01/
Thanks!
John Zavgren
-8008972
On 03/04/2013 04:28 PM, John Zavgren wrote:
Greetings:
I've posted a webrev image of a memory leak fix:
http://cr.openjdk.java.net/~jzavgren/8008972/webrev.01/
Sorry John, I don't see what the problem is that you are trying to
solve? Can you please explain why the original code has
Sent: Monday, March 4, 2013 12:59:16 PM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK-8008804
John,
closesocket call should be here.
-Dmitry
On 2013-03-04 20:12, John Zavgren wrote:
Greetings:
I posted a webrev image for a modification that eliminates a file descriptor
leak.
http
PM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK-8008804
On 04/03/2013 19:37, John Zavgren wrote:
Thanks for catching that Dmitry. I just posted a new webrev image for a
change that uses the correct procedure:
http://cr.openjdk.java.net/~jzavgren/8008804/webrev.02/
John
Shouldn't
Greetings:
I fixed numerous errors that were identified by Mr. Davidovich.
I've posed a new webrev image at:
http://cr.openjdk.java.net/~jzavgren/8007606/webrev.02/
http://cr.openjdk.java.net/%7Ejzavgren/8007606/webrev.02/
Thanks!
John Zavgren
On 02/05/2013 07:33 PM, Vitaly Davidovich wrote
I posted a new webrev image:
http://cr.openjdk.java.net/~jzavgren/4880778/webrev.02/
I made two changes:
1.) modified the indentation that's used for the argument list of the URL class
set() methods.
2.) changed the documentation for the set method in the URLStreamHandler class.
- Original
derived from URLStreamHandler are able to use this
* method to set the values of the URL fields.
It is still not great, but I think the best we can do with an old API.
-Chris.
On 04/02/2013 14:00, John Zavgren wrote:
I posted a new webrev image:
http://cr.openjdk.java.net/~jzavgren/4880778
Greetings:
Please consider the following modification of our classes for handling URLs.
http://cr.openjdk.java.net/~jzavgren/4880778/webrev.01/
background
See http://java.sun.com/j2se/1.4.2/docs/api/java/net/URL.html.
The URL class is declared final yet has two protected methods:
/webrev.07/
http://cr.openjdk.java.net/%7Ejzavgren/8005120/webrev.07/
Thank you!
John Zavgren
john.zavg...@oracle.com
On 12/20/2012 05:47 PM, John Zavgren wrote:
Greetings:
I modified my changes so that windows knows the definition of the POSIX data type:
socklen_t, and now all the system calls
On 12/28/2012 10:49 AM, John Zavgren wrote:
Please consider the following webrev for JDK-8005120.
http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.06/
(I apologize for overlooking an error in the windows code that I created in my
previous release. )
Thanks!
John Zavgren
Greetings:
I modified windows source code files so they pass size_t for buffer
sizes and socklen_t for address structures.
http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.03/
Please let me know what you think.
Thanks!
On 12/26/2012 02:56 PM, John Zavgren wrote
Greetings:
I modified the windows code so that it uses socklen_t to specify the
lengths of data structures, parameter lengths, etc. instead of ints
(which can be negative.)
http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.02/
Thanks!
John Zavgren
On 12/20/2012 05:47 PM
as that is where this code is maintained.
On 19/12/2012 15:36, John Zavgren wrote:
Greetings:
Please consider the following change to the two files:
src/share/transport/socket/sysSocket.h
src/solaris/transport/socket/socket_md.c
that eliminate compiler warnings that stem from the fact that the
variables
!
John Zavgren
On 20/12/2012 13:49, John Zavgren wrote:
Greetings:
I agree that the correct way to fix this problem is to use POSIX data
types, e.g., socklen_t. However, when I switch to the doctrinaire data type,
the build fails on windows machines:
- build monologue -
c
correctly. They were declared as integers, but they must be unsigned integers
because they are used to define buffer lengths. Were one to supply a negative
value as an argument, it would be cast into an unsigned Martian value and
there'd be (hopefully) a system call error.
Thanks!
John Zavgren
http
@openjdk.java.net
Sent: Wednesday, December 19, 2012 1:06:52 PM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK-8005120
John,
Did you consider using socklen_t instead of uint32_t and unsigned int
(for namelen etc) ?
-Dmitry
On 2012-12-19 19:36, John Zavgren wrote:
Greetings:
Please consider
/Canada Eastern
Subject: Re: RFR JDK-8005120
John,
On 2012-12-19 22:25, John Zavgren wrote:
Yes... I did consider that, but I didn't see any POSIX data types near the
code I was changing, so I decided to use a brute force data type instead.
connect, recvfrom etc almost always uses socklen_t
/webrev.00/
Thanks!
John Zavgren
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
Greetings:
The procedure initLoopbackRoutes() has a file descriptor leak.
http://cr.openjdk.java.net/~mullan/webrevs/8003991/
Thanks!
John Zavgren
2:49:46 PM GMT -05:00 US/Canada Eastern
Subject: RFR JDK-80003991
Greetings:
The procedure initLoopbackRoutes() has a file descriptor leak.
http://cr.openjdk.java.net/~mullan/webrevs/8003991/
Thanks!
John Zavgren
/
Thanks!
John Zavgren
I see after reading the correspondence that DNS would be used to bind the names
to the numbers, as in RFC 2728 :http://www.dns-sd.org/ServiceTypes.html.
(There is a convenient description here:
http://en.wikipedia.org/wiki/SRV_record.)
I wasn't aware of this effort. It's very cool and useful,
Max:
I've never seen a procedure that binds a protocol to a port number. (The http
protocol you mention usually uses TCP port number 80, but the port choice for
this protocol is up to the discretion of the programmer. The file /etc/services
binds names to numbers so that tools like tcpdump and
Greetings:
I'm requesting a review of a software change that fixes a file descriptor leak
AND a potential memory leak that involves memory reallocation (realloc()). The
webrev image is in the following location:
http://cr.openjdk.java.net/~chegar/8000203/webrev.01/
Thanks!
John Zavgren
On 24.10.2012 06:27, Chris Hegarty wrote:
Looks good to me. Thanks for going the extra mile here.
-Chris.
On 24/10/2012 14:16, John Zavgren wrote:
Greetings:
I'm requesting a review of a software change that fixes a file
descriptor leak AND a potential memory leak that involves memory
Greetings:
I'm requesting a review of a proposed change that fixes a file descriptor leak.
The webrev image is in the following location:
http://cr.openjdk.java.net/~chegar/8000203/webrev.00/
Thanks!
John Zavgren
john.zavg...@oracle.com
change any of the externally-visible behavior in the procedure.
I look forward to your comments and suggestions.
Thanks!
John Zavgren
john.zavg...@oracle.com
Yes, this seems reasonable to me too. There seem to be fewer and fewer
applications that use ftp...
- Original Message -
From: chris.hega...@oracle.com
To: alan.bate...@oracle.com
Cc: net-dev@openjdk.java.net
Sent: Monday, October 15, 2012 2:48:05 PM GMT -05:00 US/Canada Eastern
Subject:
harmless tweaks in our code than to add state information
to parfait, that would cause it to ignore certain situations. That option
seems complicated and dangerous.
Thanks!
John Zavgren
john.zavg...@oracle.com
.
Thanks!
and
RSVP
John Zavgren
john.zavg...@oracle.com
.
PlainDatagramSocketImpl.c
318 brackets is not necessary anymore
1644 whole #ifdef could be removed
struct ip_mreqn mreqn;
is not necessary anymore,
2283 the same
2294 #ifdef is not necessary anymore
-Dmitry
On 2012-09-14 22:22, John Zavgren wrote:
Greetings:
This bug
field name to be set is imr_address,
whereas when other OSes are used, the field name is: imr_interface.
Am I understanding your suggestion correctly?
Thanks!
John
-Dmitry
On 2012-09-14 22:22, John Zavgren wrote:
Greetings:
This bug (7193520) was filed because there are obsolete checks
is to format the
code, and I know that when I do a check in later on... I never have to think
about whether or not the code conforms to a style guide... because the options
I gave to indent implemented this guide. (You can do similar things with
emacs too.)
Any ideas?
Thanks!
John Zavgren
john.zavg
TestHttpsServer to be similar
to the Http equivalent. Otherwise, it looks fine to me.
And I think we'll look into migrating these tests to use the
com.sun.net.httpserver
API instead of that old implementation in the test tree.
Thanks
Michael
On 05/09/12 15:39, John Zavgren wrote:
Greetings:
Please
Kurchi:
That is a mistake.
I'll change the HTTPS name right now... and create a new webrev image.
Thanks!
John Zavgren
- Original Message -
From: kurchi.subhra.ha...@oracle.com
To: john.zavg...@oracle.com
Cc: net-dev@openjdk.java.net
Sent: Wednesday, September 5, 2012 11:54:01 AM GMT
59 matches
Mail list logo
