You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by sa...@locus.apache.org on 2000/07/12 05:41:59 UTC
cvs commit: xml-soap/java/src/org/apache/soap/util/net HTTPUtils.java
sanjiva 00/07/11 20:41:59
Modified: java/src/org/apache/soap/util/net HTTPUtils.java
Log:
Changed to use \r\n instead of println for line endings in HTTP. This
is what it should've been! Thanks to Kevin Mitchell for the work.
Submitted by: Kevin J. Mitchell (kevin.mitchell@xmls.com)
Reviewed by: Sanjiva Weerawarana (sanjiva@watson.ibm.com)
Revision Changes Path
1.3 +11 -8 xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java
Index: HTTPUtils.java
===================================================================
RCS file: /home/cvs/xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- HTTPUtils.java 2000/05/30 10:24:33 1.2
+++ HTTPUtils.java 2000/07/12 03:41:58 1.3
@@ -121,16 +121,19 @@
}
/* send it out */
- out.println (HTTP_POST + " " + url.getFile() + " HTTP/" + HTTP_VERSION);
- out.println (HEADER_HOST + ": " + url.getHost () + ':' + url.getPort ());
- out.println (HEADER_CONTENT_TYPE + ": " + contentType);
- out.println (HEADER_CONTENT_LENGTH + ": " + content.length ());
+ out.print (HTTP_POST + " " + url.getFile() + " HTTP/" + HTTP_VERSION +
+ "\r\n");
+ out.print (HEADER_HOST + ": " + url.getHost () + ':' + url.getPort () +
+ "\r\n");
+ out.print (HEADER_CONTENT_TYPE + ": " + contentType + "\r\n");
+ out.print (HEADER_CONTENT_LENGTH + ": " + content.length () + "\r\n");
for (Enumeration e = headers.keys (); e.hasMoreElements (); ) {
Object key = e.nextElement ();
- out.println (key + ": " + headers.get (key));
+ out.print (key + ": " + headers.get (key) + "\r\n");
}
- out.println ();
- out.println (content);
+ out.print ("\r\n");
+ out.print (content);
+ out.print ("\r\n\r\n");
out.flush ();
// out.close ();
@@ -185,4 +188,4 @@
return new Response (statusCode, statusString, respHeaders,
respContentLength, respContentType, in);
}
-}
\ No newline at end of file
+}
Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net
HTTPUtils.java
Posted by George I Matkovits <ma...@uswest.net>.
Sorry, I did not make myself clear.
My real objectives are the following:
o Provide a 'secure' Java SOAP implementation for my company
- optional encrypted (PKI based) communications between end-points (when
connection is to a < HTTPS: some URI>)
- automated form based session login into the server
o transmission of all 'serializable' Java objects and not just the 'basic'
elements
defined by the SoapV1.1 spec.
o a directly Java callable RPC bean based interface (with the XML wrapper
provided by the interface beans) to support the above
Currently I have a very simple 'soapish' like transport with a URL connection to a
server side servlet to provide a 'secure' transport. It is missing the true XML
support in IBM's reference implementation but it allows the use of Java's JSSE
when requested and supported by the server (currently an Apache 1.3.12 and Tomcat
3.2b1 on Linux). (the current IBM 'base' code does not directly support
connections via Apache due to how the socket information is extracted from the
client provided URL, a fix is simple). Our 'soapish' application was created to
show how easy it is to build a Java based secure server-to-server internet
capable, firewall piercing http transport . XML is used only for configuration
and to describe the 'inline' serialized Java objects.
An url connection object also provides the I/O streams for the direct transport of
I64 encoded, serialized Java objects. This approach is LESS error prone then the
current 'print' approach used in the reference implementation.
Your below restructuring objectives WILL probably provide all the required
enhancement for supporting my company's requirements.
BUT
my REAL PROBLEM is: according to the current USA law (IMHO) no strong encryption
code, any architecture discussions or any other cryptography related information
can be published on the internet without restricting to local US access! Since
this not is only about 'how to stay within the law' I might be OK.
How could we do this within the current apache framework? Adding encryption to a
slightly extended IBM SOAP (if the connection is to a servlet url) is relatively
easy. Working within the current law in the 'open apache environment' is almost
impossible, could we create a 'secured' Apache 'SOAP' site?
p.s. Without some from of security extensions the V1.1 Soap architecture is
rather limited (I hope that IETF will not approve it without some kind of
'security' addendum because any V1.1. based SOAP will demolish any firewall
provided site protection), unless communication is between NT pairs when NT's
IPSEC can be used. Unfortunately the later option is not open to the current
generation of Unix (or Linux) systems!
Is this the 'hidden' intention of Microsoft's current V1.1 soap spec? (-
For a truly 'open' and 'secure' SOAP implementation the optional support of
Java's JSSE architecture is imperative on all Java platforms. If we do not do it
here then someone will do it outside the USA like it was done with Apache's
mod-ssl, the open-SSL code, etc....
How are we going to do it within the framework of current USA law? We must!
Regards - George
(sorry for the long rambling but you are one of the very few people (IMHO) who
could make SOAP+ into the transport of the truly open internet age!)
Sanjiva Weerawarana wrote:
> > I am also not sure about the endian problem! I would very much like to see a
> > stream and not print based output, the current implementation IMHO is not
> very
> > well structured in this respect.... (-
>
> Could you expand on this a bit? I'm not sure I understand what you meant
> by stream vs. print.
>
> The current implementation could definitely do with major restructuring.
> I think at least the following are essential:
> - use SAX at the lower level
> - expose a messaging API and a management framework for it
> - expose an RPC API and a management framework for it (this is pretty
> much what the current code does)
> - sort out the lifecycle management stuff in a transport-independent
> manner
> - set up for better integration to different transports
> - the serializer/deserializer stuff needs re-thinking
> All of this needs to be done without blowing up the code size needlessly.
>
> I hope that the next major rev of this codebase will tackle some of
> these issues .. it of course depends on the degree of community
> participation!
>
> Sanjiva.
Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net
HTTPUtils.java
Posted by George I Matkovits <ma...@uswest.net>.
Sorry, I did not make myself clear.
My real objectives are the following:
o Provide a 'secure' Java SOAP implementation for my company
- optional encrypted (PKI based) communications between end-points (when
connection is to a < HTTPS: some URI>)
- automated form based session login into the server
o transmission of all 'serializable' Java objects and not just the 'basic'
elements
defined by the SoapV1.1 spec.
o a directly Java callable RPC bean based interface (with the XML wrapper
provided by the interface beans) to support the above
Currently I have a very simple 'soapish' like transport with a URL connection to a
server side servlet to provide a 'secure' transport. It is missing the true XML
support in IBM's reference implementation but it allows the use of Java's JSSE
when requested and supported by the server (currently an Apache 1.3.12 and Tomcat
3.2b1 on Linux). (the current IBM 'base' code does not directly support
connections via Apache due to how the socket information is extracted from the
client provided URL, a fix is simple). Our 'soapish' application was created to
show how easy it is to build a Java based secure server-to-server internet
capable, firewall piercing http transport . XML is used only for configuration
and to describe the 'inline' serialized Java objects.
An url connection object also provides the I/O streams for the direct transport of
I64 encoded, serialized Java objects. This approach is LESS error prone then the
current 'print' approach used in the reference implementation.
Your below restructuring objectives WILL probably provide all the required
enhancement for supporting my company's requirements.
BUT
my REAL PROBLEM is: according to the current USA law (IMHO) no strong encryption
code, any architecture discussions or any other cryptography related information
can be published on the internet without restricting to local US access! Since
this not is only about 'how to stay within the law' I might be OK.
How could we do this within the current apache framework? Adding encryption to a
slightly extended IBM SOAP (if the connection is to a servlet url) is relatively
easy. Working within the current law in the 'open apache environment' is almost
impossible, could we create a 'secured' Apache 'SOAP' site?
p.s. Without some from of security extensions the V1.1 Soap architecture is
rather limited (I hope that IETF will not approve it without some kind of
'security' addendum because any V1.1. based SOAP will demolish any firewall
provided site protection), unless communication is between NT pairs when NT's
IPSEC can be used. Unfortunately the later option is not open to the current
generation of Unix (or Linux) systems!
Is this the 'hidden' intention of Microsoft's current V1.1 soap spec? (-
For a truly 'open' and 'secure' SOAP implementation the optional support of
Java's JSSE architecture is imperative on all Java platforms. If we do not do it
here then someone will do it outside the USA like it was done with Apache's
mod-ssl, the open-SSL code, etc....
How are we going to do it within the framework of current USA law? We must!
Regards - George
(sorry for the long rambling but you are one of the very few people (IMHO) who
could make SOAP+ into the transport of the truly open internet age!)
Sanjiva Weerawarana wrote:
> > I am also not sure about the endian problem! I would very much like to see a
> > stream and not print based output, the current implementation IMHO is not
> very
> > well structured in this respect.... (-
>
> Could you expand on this a bit? I'm not sure I understand what you meant
> by stream vs. print.
>
> The current implementation could definitely do with major restructuring.
> I think at least the following are essential:
> - use SAX at the lower level
> - expose a messaging API and a management framework for it
> - expose an RPC API and a management framework for it (this is pretty
> much what the current code does)
> - sort out the lifecycle management stuff in a transport-independent
> manner
> - set up for better integration to different transports
> - the serializer/deserializer stuff needs re-thinking
> All of this needs to be done without blowing up the code size needlessly.
>
> I hope that the next major rev of this codebase will tackle some of
> these issues .. it of course depends on the degree of community
> participation!
>
> Sanjiva.
RE: cvs commit: xml-soap/java/src/org/apache/soap/util/net HTTPUtils.java
Posted by Steven McDowall <sj...@aptest.com>.
Two things:
1) I agree with you Sanjiva.. Geroge, could you explain a little more about
what
you mean by a stream based output? In effect, a JSP does generate a stream
of output, already setup by Tomcat (it creates the "out" stream as a
PrintWriter object for you).
Since SOAP uses XML issuing a stream of characters (via println) is entirely
reasonable
and we should not see ANY endian problems since we are dealing with
"characters"..
This sort of DOES bring up the question as to why we did see the difference
between
W2K and Unix (Linux only maybe?) since we really should NOT have had to emit
a "\r"
for "Unix".. I have written numerous Servlets (not JSP) under Linux and
never had
to do this .. Very odd.. Also, Geogre also points out that the symptoms go
"away"
under Tomcat 3.2b1 (or, that is what I am gathering by his message). I
wonder if
found an odd bug in Tomcat 3.1?
2) As for you other points Sanjiva (the "todo" list for the next version) ..
They sound all pretty good. I did have one more question though, do we not
desire to have a Java Servlet (pure) version of the rpcrouter logic instead
of
the JSP version? I am very interested in this myself.. :-)
-Steve
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Thursday, July 13, 2000 11:46 PM
To: soap-dev@xml.apache.org
Subject: Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net
HTTPUtils.java
> I am also not sure about the endian problem! I would very much like to see
a
> stream and not print based output, the current implementation IMHO is not
very
> well structured in this respect.... (-
Could you expand on this a bit? I'm not sure I understand what you meant
by stream vs. print.
The current implementation could definitely do with major restructuring.
I think at least the following are essential:
- use SAX at the lower level
- expose a messaging API and a management framework for it
- expose an RPC API and a management framework for it (this is pretty
much what the current code does)
- sort out the lifecycle management stuff in a transport-independent
manner
- set up for better integration to different transports
- the serializer/deserializer stuff needs re-thinking
All of this needs to be done without blowing up the code size needlessly.
I hope that the next major rev of this codebase will tackle some of
these issues .. it of course depends on the degree of community
participation!
Sanjiva.
RE: cvs commit: xml-soap/java/src/org/apache/soap/util/net HTTPUtils.java
Posted by Steven McDowall <sj...@aptest.com>.
Two things:
1) I agree with you Sanjiva.. Geroge, could you explain a little more about
what
you mean by a stream based output? In effect, a JSP does generate a stream
of output, already setup by Tomcat (it creates the "out" stream as a
PrintWriter object for you).
Since SOAP uses XML issuing a stream of characters (via println) is entirely
reasonable
and we should not see ANY endian problems since we are dealing with
"characters"..
This sort of DOES bring up the question as to why we did see the difference
between
W2K and Unix (Linux only maybe?) since we really should NOT have had to emit
a "\r"
for "Unix".. I have written numerous Servlets (not JSP) under Linux and
never had
to do this .. Very odd.. Also, Geogre also points out that the symptoms go
"away"
under Tomcat 3.2b1 (or, that is what I am gathering by his message). I
wonder if
found an odd bug in Tomcat 3.1?
2) As for you other points Sanjiva (the "todo" list for the next version) ..
They sound all pretty good. I did have one more question though, do we not
desire to have a Java Servlet (pure) version of the rpcrouter logic instead
of
the JSP version? I am very interested in this myself.. :-)
-Steve
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Thursday, July 13, 2000 11:46 PM
To: soap-dev@xml.apache.org
Subject: Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net
HTTPUtils.java
> I am also not sure about the endian problem! I would very much like to see
a
> stream and not print based output, the current implementation IMHO is not
very
> well structured in this respect.... (-
Could you expand on this a bit? I'm not sure I understand what you meant
by stream vs. print.
The current implementation could definitely do with major restructuring.
I think at least the following are essential:
- use SAX at the lower level
- expose a messaging API and a management framework for it
- expose an RPC API and a management framework for it (this is pretty
much what the current code does)
- sort out the lifecycle management stuff in a transport-independent
manner
- set up for better integration to different transports
- the serializer/deserializer stuff needs re-thinking
All of this needs to be done without blowing up the code size needlessly.
I hope that the next major rev of this codebase will tackle some of
these issues .. it of course depends on the degree of community
participation!
Sanjiva.
Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net HTTPUtils.java
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
> I am also not sure about the endian problem! I would very much like to see a
> stream and not print based output, the current implementation IMHO is not
very
> well structured in this respect.... (-
Could you expand on this a bit? I'm not sure I understand what you meant
by stream vs. print.
The current implementation could definitely do with major restructuring.
I think at least the following are essential:
- use SAX at the lower level
- expose a messaging API and a management framework for it
- expose an RPC API and a management framework for it (this is pretty
much what the current code does)
- sort out the lifecycle management stuff in a transport-independent
manner
- set up for better integration to different transports
- the serializer/deserializer stuff needs re-thinking
All of this needs to be done without blowing up the code size needlessly.
I hope that the next major rev of this codebase will tackle some of
these issues .. it of course depends on the degree of community
participation!
Sanjiva.
Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net HTTPUtils.java
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
> I am also not sure about the endian problem! I would very much like to see a
> stream and not print based output, the current implementation IMHO is not
very
> well structured in this respect.... (-
Could you expand on this a bit? I'm not sure I understand what you meant
by stream vs. print.
The current implementation could definitely do with major restructuring.
I think at least the following are essential:
- use SAX at the lower level
- expose a messaging API and a management framework for it
- expose an RPC API and a management framework for it (this is pretty
much what the current code does)
- sort out the lifecycle management stuff in a transport-independent
manner
- set up for better integration to different transports
- the serializer/deserializer stuff needs re-thinking
All of this needs to be done without blowing up the code size needlessly.
I hope that the next major rev of this codebase will tackle some of
these issues .. it of course depends on the degree of community
participation!
Sanjiva.
Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net
HTTPUtils.java
Posted by George I Matkovits <ma...@uswest.net>.
The CR problems is different, it is a DOS-NT vs Unix difference, LINUX IS UNIX!
I also had it on Linux and it behaves differently on tomcat3.1 and 3.2B1
because of buffer sizes.
I am also not sure about the endian problem! I would very much like to see a
stream and not print based output, the current implementation IMHO is not very
well structured in this respect.... (-
"Steven J. McDowall" wrote:
> Actually it WAS on Intel / Linux where the problem was found! :-)
>
> I don't think anything in the space of "characters" are much affected
> by big/little endian problems.. Streams of characters should be fine
> regardless of h/w architecture I think.. :-)
>
> -Steve
>
> -----Original Message-----
> From: George I Matkovits [mailto:matkovitsg@uswest.net]
> Sent: Thursday, July 13, 2000 8:59 PM
> To: soap-dev@xml.apache.org
> Subject: Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net
> HTTPUtils.java
>
> Are we going to have littl/big endian problems with these prints directly
> into the
> http stream? Since Linux also runs on Intel boxes (little endian?)we will
> not be able
> to see the problem there! IMHO prints do not provide network byte order !
>
> sanjiva@locus.apache.org wrote:
>
> > sanjiva 00/07/11 20:41:59
> >
> > Modified: java/src/org/apache/soap/util/net HTTPUtils.java
> > Log:
> > Changed to use \r\n instead of println for line endings in HTTP. This
> > is what it should've been! Thanks to Kevin Mitchell for the work.
> > Submitted by: Kevin J. Mitchell (kevin.mitchell@xmls.com)
> > Reviewed by: Sanjiva Weerawarana (sanjiva@watson.ibm.com)
> >
> > Revision Changes Path
> > 1.3 +11 -8
> xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java
> >
> > Index: HTTPUtils.java
> > ===================================================================
> > RCS file:
> /home/cvs/xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java,v
> > retrieving revision 1.2
> > retrieving revision 1.3
> > diff -u -r1.2 -r1.3
> > --- HTTPUtils.java 2000/05/30 10:24:33 1.2
> > +++ HTTPUtils.java 2000/07/12 03:41:58 1.3
> > @@ -121,16 +121,19 @@
> > }
> >
> > /* send it out */
> > - out.println (HTTP_POST + " " + url.getFile() + " HTTP/" +
> HTTP_VERSION);
> > - out.println (HEADER_HOST + ": " + url.getHost () + ':' +
> url.getPort ());
> > - out.println (HEADER_CONTENT_TYPE + ": " + contentType);
> > - out.println (HEADER_CONTENT_LENGTH + ": " + content.length ());
> > + out.print (HTTP_POST + " " + url.getFile() + " HTTP/" +
> HTTP_VERSION +
> > + "\r\n");
> > + out.print (HEADER_HOST + ": " + url.getHost () + ':' + url.getPort
> () +
> > + "\r\n");
> > + out.print (HEADER_CONTENT_TYPE + ": " + contentType + "\r\n");
> > + out.print (HEADER_CONTENT_LENGTH + ": " + content.length () +
> "\r\n");
> > for (Enumeration e = headers.keys (); e.hasMoreElements (); ) {
> > Object key = e.nextElement ();
> > - out.println (key + ": " + headers.get (key));
> > + out.print (key + ": " + headers.get (key) + "\r\n");
> > }
> > - out.println ();
> > - out.println (content);
> > + out.print ("\r\n");
> > + out.print (content);
> > + out.print ("\r\n\r\n");
> > out.flush ();
> > // out.close ();
> >
> > @@ -185,4 +188,4 @@
> > return new Response (statusCode, statusString, respHeaders,
> > respContentLength, respContentType, in);
> > }
> > -}
> > \ No newline at end of file
> > +}
> >
> >
> >
Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net
HTTPUtils.java
Posted by George I Matkovits <ma...@uswest.net>.
The CR problems is different, it is a DOS-NT vs Unix difference, LINUX IS UNIX!
I also had it on Linux and it behaves differently on tomcat3.1 and 3.2B1
because of buffer sizes.
I am also not sure about the endian problem! I would very much like to see a
stream and not print based output, the current implementation IMHO is not very
well structured in this respect.... (-
"Steven J. McDowall" wrote:
> Actually it WAS on Intel / Linux where the problem was found! :-)
>
> I don't think anything in the space of "characters" are much affected
> by big/little endian problems.. Streams of characters should be fine
> regardless of h/w architecture I think.. :-)
>
> -Steve
>
> -----Original Message-----
> From: George I Matkovits [mailto:matkovitsg@uswest.net]
> Sent: Thursday, July 13, 2000 8:59 PM
> To: soap-dev@xml.apache.org
> Subject: Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net
> HTTPUtils.java
>
> Are we going to have littl/big endian problems with these prints directly
> into the
> http stream? Since Linux also runs on Intel boxes (little endian?)we will
> not be able
> to see the problem there! IMHO prints do not provide network byte order !
>
> sanjiva@locus.apache.org wrote:
>
> > sanjiva 00/07/11 20:41:59
> >
> > Modified: java/src/org/apache/soap/util/net HTTPUtils.java
> > Log:
> > Changed to use \r\n instead of println for line endings in HTTP. This
> > is what it should've been! Thanks to Kevin Mitchell for the work.
> > Submitted by: Kevin J. Mitchell (kevin.mitchell@xmls.com)
> > Reviewed by: Sanjiva Weerawarana (sanjiva@watson.ibm.com)
> >
> > Revision Changes Path
> > 1.3 +11 -8
> xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java
> >
> > Index: HTTPUtils.java
> > ===================================================================
> > RCS file:
> /home/cvs/xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java,v
> > retrieving revision 1.2
> > retrieving revision 1.3
> > diff -u -r1.2 -r1.3
> > --- HTTPUtils.java 2000/05/30 10:24:33 1.2
> > +++ HTTPUtils.java 2000/07/12 03:41:58 1.3
> > @@ -121,16 +121,19 @@
> > }
> >
> > /* send it out */
> > - out.println (HTTP_POST + " " + url.getFile() + " HTTP/" +
> HTTP_VERSION);
> > - out.println (HEADER_HOST + ": " + url.getHost () + ':' +
> url.getPort ());
> > - out.println (HEADER_CONTENT_TYPE + ": " + contentType);
> > - out.println (HEADER_CONTENT_LENGTH + ": " + content.length ());
> > + out.print (HTTP_POST + " " + url.getFile() + " HTTP/" +
> HTTP_VERSION +
> > + "\r\n");
> > + out.print (HEADER_HOST + ": " + url.getHost () + ':' + url.getPort
> () +
> > + "\r\n");
> > + out.print (HEADER_CONTENT_TYPE + ": " + contentType + "\r\n");
> > + out.print (HEADER_CONTENT_LENGTH + ": " + content.length () +
> "\r\n");
> > for (Enumeration e = headers.keys (); e.hasMoreElements (); ) {
> > Object key = e.nextElement ();
> > - out.println (key + ": " + headers.get (key));
> > + out.print (key + ": " + headers.get (key) + "\r\n");
> > }
> > - out.println ();
> > - out.println (content);
> > + out.print ("\r\n");
> > + out.print (content);
> > + out.print ("\r\n\r\n");
> > out.flush ();
> > // out.close ();
> >
> > @@ -185,4 +188,4 @@
> > return new Response (statusCode, statusString, respHeaders,
> > respContentLength, respContentType, in);
> > }
> > -}
> > \ No newline at end of file
> > +}
> >
> >
> >
RE: cvs commit: xml-soap/java/src/org/apache/soap/util/net HTTPUtils.java
Posted by "Steven J. McDowall" <sj...@uswest.net>.
Actually it WAS on Intel / Linux where the problem was found! :-)
I don't think anything in the space of "characters" are much affected
by big/little endian problems.. Streams of characters should be fine
regardless of h/w architecture I think.. :-)
-Steve
-----Original Message-----
From: George I Matkovits [mailto:matkovitsg@uswest.net]
Sent: Thursday, July 13, 2000 8:59 PM
To: soap-dev@xml.apache.org
Subject: Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net
HTTPUtils.java
Are we going to have littl/big endian problems with these prints directly
into the
http stream? Since Linux also runs on Intel boxes (little endian?)we will
not be able
to see the problem there! IMHO prints do not provide network byte order !
sanjiva@locus.apache.org wrote:
> sanjiva 00/07/11 20:41:59
>
> Modified: java/src/org/apache/soap/util/net HTTPUtils.java
> Log:
> Changed to use \r\n instead of println for line endings in HTTP. This
> is what it should've been! Thanks to Kevin Mitchell for the work.
> Submitted by: Kevin J. Mitchell (kevin.mitchell@xmls.com)
> Reviewed by: Sanjiva Weerawarana (sanjiva@watson.ibm.com)
>
> Revision Changes Path
> 1.3 +11 -8
xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java
>
> Index: HTTPUtils.java
> ===================================================================
> RCS file:
/home/cvs/xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- HTTPUtils.java 2000/05/30 10:24:33 1.2
> +++ HTTPUtils.java 2000/07/12 03:41:58 1.3
> @@ -121,16 +121,19 @@
> }
>
> /* send it out */
> - out.println (HTTP_POST + " " + url.getFile() + " HTTP/" +
HTTP_VERSION);
> - out.println (HEADER_HOST + ": " + url.getHost () + ':' +
url.getPort ());
> - out.println (HEADER_CONTENT_TYPE + ": " + contentType);
> - out.println (HEADER_CONTENT_LENGTH + ": " + content.length ());
> + out.print (HTTP_POST + " " + url.getFile() + " HTTP/" +
HTTP_VERSION +
> + "\r\n");
> + out.print (HEADER_HOST + ": " + url.getHost () + ':' + url.getPort
() +
> + "\r\n");
> + out.print (HEADER_CONTENT_TYPE + ": " + contentType + "\r\n");
> + out.print (HEADER_CONTENT_LENGTH + ": " + content.length () +
"\r\n");
> for (Enumeration e = headers.keys (); e.hasMoreElements (); ) {
> Object key = e.nextElement ();
> - out.println (key + ": " + headers.get (key));
> + out.print (key + ": " + headers.get (key) + "\r\n");
> }
> - out.println ();
> - out.println (content);
> + out.print ("\r\n");
> + out.print (content);
> + out.print ("\r\n\r\n");
> out.flush ();
> // out.close ();
>
> @@ -185,4 +188,4 @@
> return new Response (statusCode, statusString, respHeaders,
> respContentLength, respContentType, in);
> }
> -}
> \ No newline at end of file
> +}
>
>
>
RE: cvs commit: xml-soap/java/src/org/apache/soap/util/net HTTPUtils.java
Posted by "Steven J. McDowall" <sj...@uswest.net>.
Actually it WAS on Intel / Linux where the problem was found! :-)
I don't think anything in the space of "characters" are much affected
by big/little endian problems.. Streams of characters should be fine
regardless of h/w architecture I think.. :-)
-Steve
-----Original Message-----
From: George I Matkovits [mailto:matkovitsg@uswest.net]
Sent: Thursday, July 13, 2000 8:59 PM
To: soap-dev@xml.apache.org
Subject: Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net
HTTPUtils.java
Are we going to have littl/big endian problems with these prints directly
into the
http stream? Since Linux also runs on Intel boxes (little endian?)we will
not be able
to see the problem there! IMHO prints do not provide network byte order !
sanjiva@locus.apache.org wrote:
> sanjiva 00/07/11 20:41:59
>
> Modified: java/src/org/apache/soap/util/net HTTPUtils.java
> Log:
> Changed to use \r\n instead of println for line endings in HTTP. This
> is what it should've been! Thanks to Kevin Mitchell for the work.
> Submitted by: Kevin J. Mitchell (kevin.mitchell@xmls.com)
> Reviewed by: Sanjiva Weerawarana (sanjiva@watson.ibm.com)
>
> Revision Changes Path
> 1.3 +11 -8
xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java
>
> Index: HTTPUtils.java
> ===================================================================
> RCS file:
/home/cvs/xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- HTTPUtils.java 2000/05/30 10:24:33 1.2
> +++ HTTPUtils.java 2000/07/12 03:41:58 1.3
> @@ -121,16 +121,19 @@
> }
>
> /* send it out */
> - out.println (HTTP_POST + " " + url.getFile() + " HTTP/" +
HTTP_VERSION);
> - out.println (HEADER_HOST + ": " + url.getHost () + ':' +
url.getPort ());
> - out.println (HEADER_CONTENT_TYPE + ": " + contentType);
> - out.println (HEADER_CONTENT_LENGTH + ": " + content.length ());
> + out.print (HTTP_POST + " " + url.getFile() + " HTTP/" +
HTTP_VERSION +
> + "\r\n");
> + out.print (HEADER_HOST + ": " + url.getHost () + ':' + url.getPort
() +
> + "\r\n");
> + out.print (HEADER_CONTENT_TYPE + ": " + contentType + "\r\n");
> + out.print (HEADER_CONTENT_LENGTH + ": " + content.length () +
"\r\n");
> for (Enumeration e = headers.keys (); e.hasMoreElements (); ) {
> Object key = e.nextElement ();
> - out.println (key + ": " + headers.get (key));
> + out.print (key + ": " + headers.get (key) + "\r\n");
> }
> - out.println ();
> - out.println (content);
> + out.print ("\r\n");
> + out.print (content);
> + out.print ("\r\n\r\n");
> out.flush ();
> // out.close ();
>
> @@ -185,4 +188,4 @@
> return new Response (statusCode, statusString, respHeaders,
> respContentLength, respContentType, in);
> }
> -}
> \ No newline at end of file
> +}
>
>
>
Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net
HTTPUtils.java
Posted by George I Matkovits <ma...@uswest.net>.
Are we going to have littl/big endian problems with these prints directly into the
http stream? Since Linux also runs on Intel boxes (little endian?)we will not be able
to see the problem there! IMHO prints do not provide network byte order !
sanjiva@locus.apache.org wrote:
> sanjiva 00/07/11 20:41:59
>
> Modified: java/src/org/apache/soap/util/net HTTPUtils.java
> Log:
> Changed to use \r\n instead of println for line endings in HTTP. This
> is what it should've been! Thanks to Kevin Mitchell for the work.
> Submitted by: Kevin J. Mitchell (kevin.mitchell@xmls.com)
> Reviewed by: Sanjiva Weerawarana (sanjiva@watson.ibm.com)
>
> Revision Changes Path
> 1.3 +11 -8 xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java
>
> Index: HTTPUtils.java
> ===================================================================
> RCS file: /home/cvs/xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- HTTPUtils.java 2000/05/30 10:24:33 1.2
> +++ HTTPUtils.java 2000/07/12 03:41:58 1.3
> @@ -121,16 +121,19 @@
> }
>
> /* send it out */
> - out.println (HTTP_POST + " " + url.getFile() + " HTTP/" + HTTP_VERSION);
> - out.println (HEADER_HOST + ": " + url.getHost () + ':' + url.getPort ());
> - out.println (HEADER_CONTENT_TYPE + ": " + contentType);
> - out.println (HEADER_CONTENT_LENGTH + ": " + content.length ());
> + out.print (HTTP_POST + " " + url.getFile() + " HTTP/" + HTTP_VERSION +
> + "\r\n");
> + out.print (HEADER_HOST + ": " + url.getHost () + ':' + url.getPort () +
> + "\r\n");
> + out.print (HEADER_CONTENT_TYPE + ": " + contentType + "\r\n");
> + out.print (HEADER_CONTENT_LENGTH + ": " + content.length () + "\r\n");
> for (Enumeration e = headers.keys (); e.hasMoreElements (); ) {
> Object key = e.nextElement ();
> - out.println (key + ": " + headers.get (key));
> + out.print (key + ": " + headers.get (key) + "\r\n");
> }
> - out.println ();
> - out.println (content);
> + out.print ("\r\n");
> + out.print (content);
> + out.print ("\r\n\r\n");
> out.flush ();
> // out.close ();
>
> @@ -185,4 +188,4 @@
> return new Response (statusCode, statusString, respHeaders,
> respContentLength, respContentType, in);
> }
> -}
> \ No newline at end of file
> +}
>
>
>
Re: cvs commit: xml-soap/java/src/org/apache/soap/util/net
HTTPUtils.java
Posted by George I Matkovits <ma...@uswest.net>.
Are we going to have littl/big endian problems with these prints directly into the
http stream? Since Linux also runs on Intel boxes (little endian?)we will not be able
to see the problem there! IMHO prints do not provide network byte order !
sanjiva@locus.apache.org wrote:
> sanjiva 00/07/11 20:41:59
>
> Modified: java/src/org/apache/soap/util/net HTTPUtils.java
> Log:
> Changed to use \r\n instead of println for line endings in HTTP. This
> is what it should've been! Thanks to Kevin Mitchell for the work.
> Submitted by: Kevin J. Mitchell (kevin.mitchell@xmls.com)
> Reviewed by: Sanjiva Weerawarana (sanjiva@watson.ibm.com)
>
> Revision Changes Path
> 1.3 +11 -8 xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java
>
> Index: HTTPUtils.java
> ===================================================================
> RCS file: /home/cvs/xml-soap/java/src/org/apache/soap/util/net/HTTPUtils.java,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- HTTPUtils.java 2000/05/30 10:24:33 1.2
> +++ HTTPUtils.java 2000/07/12 03:41:58 1.3
> @@ -121,16 +121,19 @@
> }
>
> /* send it out */
> - out.println (HTTP_POST + " " + url.getFile() + " HTTP/" + HTTP_VERSION);
> - out.println (HEADER_HOST + ": " + url.getHost () + ':' + url.getPort ());
> - out.println (HEADER_CONTENT_TYPE + ": " + contentType);
> - out.println (HEADER_CONTENT_LENGTH + ": " + content.length ());
> + out.print (HTTP_POST + " " + url.getFile() + " HTTP/" + HTTP_VERSION +
> + "\r\n");
> + out.print (HEADER_HOST + ": " + url.getHost () + ':' + url.getPort () +
> + "\r\n");
> + out.print (HEADER_CONTENT_TYPE + ": " + contentType + "\r\n");
> + out.print (HEADER_CONTENT_LENGTH + ": " + content.length () + "\r\n");
> for (Enumeration e = headers.keys (); e.hasMoreElements (); ) {
> Object key = e.nextElement ();
> - out.println (key + ": " + headers.get (key));
> + out.print (key + ": " + headers.get (key) + "\r\n");
> }
> - out.println ();
> - out.println (content);
> + out.print ("\r\n");
> + out.print (content);
> + out.print ("\r\n\r\n");
> out.flush ();
> // out.close ();
>
> @@ -185,4 +188,4 @@
> return new Response (statusCode, statusString, respHeaders,
> respContentLength, respContentType, in);
> }
> -}
> \ No newline at end of file
> +}
>
>
>