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 Michael Brennan <Mi...@Allegis.com> on 2000/07/14 22:51:24 UTC
HTTP protocol implementation
Here's another implementation question I have. (Again, I hope folks don't
mind my asking.)
The current HTTP protocol support seems very lightweight. What are the plans
going forward? Any consideration of using third party HTTP lib? I've been
looking, for instance, at the HTTP client library from the W3C included in
the Jigsaw distribution. Rich support for HTTP/1.1 including authentication,
cookies, chunked encoding, etc. Also has a very extensible architecture. For
instance, the ability to attach filters that can modify requests or
responses (this is how support for cookies, authentication, etc, is
implemented). It seems like there is some reinventing of the wheel going on
with the protocol support.
I also noticed that the HTTPUtils.post method creates a PrintWriter for
output on top of the output stream. That results in the local system default
character encoding being used. Isn't this a bit dangerous? Shouldn't this be
explicitly specifying, perhaps, a utf-8 encoding? Likewise with the Reader
for reading the response.
I'm very much a novice with SOAP and this implementation, so I apologize in
advance if these are naive questions.
Thanks.
Re: HTTP protocol implementation
Posted by George I Matkovits <ma...@uswest.net>.
I should have said: I64 encoded and serialized Java Objects below ....
Sorry - George
George I Matkovits wrote:
> Please also look at the Java2 APIs for HTTP support from inside servlets. Most
> good servlet books cover http tunneling and things like cookies, session
> management, authentication, PKI managed SSL support with JSSE is not as widely
> documented yet but can be made to work.
> It is NOT just XML all the way!
> Serialized Java objects can be directly transmitted over http without platform
> dependent prints. In addition, what Soap will provide is the option for a
> consistent standard of an end to and interface. The XML based interface
> definition will allow (eventually) true B2B, when the other requirements like
> data privacy and security will be also satisfied. If we here do not find a
> 'generic' and open solution for the security issues, SOAP will not make it IMHO
> and the Internet standard's body IETF will be open to billion dollar law suits.
> Regards -George
>
> Michael Brennan wrote:
>
> > Here's another implementation question I have. (Again, I hope folks don't
> > mind my asking.)
> >
> > The current HTTP protocol support seems very lightweight. What are the plans
> > going forward? Any consideration of using third party HTTP lib? I've been
> > looking, for instance, at the HTTP client library from the W3C included in
> > the Jigsaw distribution. Rich support for HTTP/1.1 including authentication,
> > cookies, chunked encoding, etc. Also has a very extensible architecture. For
> > instance, the ability to attach filters that can modify requests or
> > responses (this is how support for cookies, authentication, etc, is
> > implemented). It seems like there is some reinventing of the wheel going on
> > with the protocol support.
> >
> > I also noticed that the HTTPUtils.post method creates a PrintWriter for
> > output on top of the output stream. That results in the local system default
> > character encoding being used. Isn't this a bit dangerous? Shouldn't this be
> > explicitly specifying, perhaps, a utf-8 encoding? Likewise with the Reader
> > for reading the response.
> >
> > I'm very much a novice with SOAP and this implementation, so I apologize in
> > advance if these are naive questions.
> >
> > Thanks.
Re: HTTP protocol implementation
Posted by George I Matkovits <ma...@uswest.net>.
I should have said: I64 encoded and serialized Java Objects below ....
Sorry - George
George I Matkovits wrote:
> Please also look at the Java2 APIs for HTTP support from inside servlets. Most
> good servlet books cover http tunneling and things like cookies, session
> management, authentication, PKI managed SSL support with JSSE is not as widely
> documented yet but can be made to work.
> It is NOT just XML all the way!
> Serialized Java objects can be directly transmitted over http without platform
> dependent prints. In addition, what Soap will provide is the option for a
> consistent standard of an end to and interface. The XML based interface
> definition will allow (eventually) true B2B, when the other requirements like
> data privacy and security will be also satisfied. If we here do not find a
> 'generic' and open solution for the security issues, SOAP will not make it IMHO
> and the Internet standard's body IETF will be open to billion dollar law suits.
> Regards -George
>
> Michael Brennan wrote:
>
> > Here's another implementation question I have. (Again, I hope folks don't
> > mind my asking.)
> >
> > The current HTTP protocol support seems very lightweight. What are the plans
> > going forward? Any consideration of using third party HTTP lib? I've been
> > looking, for instance, at the HTTP client library from the W3C included in
> > the Jigsaw distribution. Rich support for HTTP/1.1 including authentication,
> > cookies, chunked encoding, etc. Also has a very extensible architecture. For
> > instance, the ability to attach filters that can modify requests or
> > responses (this is how support for cookies, authentication, etc, is
> > implemented). It seems like there is some reinventing of the wheel going on
> > with the protocol support.
> >
> > I also noticed that the HTTPUtils.post method creates a PrintWriter for
> > output on top of the output stream. That results in the local system default
> > character encoding being used. Isn't this a bit dangerous? Shouldn't this be
> > explicitly specifying, perhaps, a utf-8 encoding? Likewise with the Reader
> > for reading the response.
> >
> > I'm very much a novice with SOAP and this implementation, so I apologize in
> > advance if these are naive questions.
> >
> > Thanks.
Re: HTTP protocol implementation
Posted by George I Matkovits <ma...@uswest.net>.
Please also look at the Java2 APIs for HTTP support from inside servlets. Most
good servlet books cover http tunneling and things like cookies, session
management, authentication, PKI managed SSL support with JSSE is not as widely
documented yet but can be made to work.
It is NOT just XML all the way!
Serialized Java objects can be directly transmitted over http without platform
dependent prints. In addition, what Soap will provide is the option for a
consistent standard of an end to and interface. The XML based interface
definition will allow (eventually) true B2B, when the other requirements like
data privacy and security will be also satisfied. If we here do not find a
'generic' and open solution for the security issues, SOAP will not make it IMHO
and the Internet standard's body IETF will be open to billion dollar law suits.
Regards -George
Michael Brennan wrote:
> Here's another implementation question I have. (Again, I hope folks don't
> mind my asking.)
>
> The current HTTP protocol support seems very lightweight. What are the plans
> going forward? Any consideration of using third party HTTP lib? I've been
> looking, for instance, at the HTTP client library from the W3C included in
> the Jigsaw distribution. Rich support for HTTP/1.1 including authentication,
> cookies, chunked encoding, etc. Also has a very extensible architecture. For
> instance, the ability to attach filters that can modify requests or
> responses (this is how support for cookies, authentication, etc, is
> implemented). It seems like there is some reinventing of the wheel going on
> with the protocol support.
>
> I also noticed that the HTTPUtils.post method creates a PrintWriter for
> output on top of the output stream. That results in the local system default
> character encoding being used. Isn't this a bit dangerous? Shouldn't this be
> explicitly specifying, perhaps, a utf-8 encoding? Likewise with the Reader
> for reading the response.
>
> I'm very much a novice with SOAP and this implementation, so I apologize in
> advance if these are naive questions.
>
> Thanks.
Re: HTTP protocol implementation
Posted by George I Matkovits <ma...@uswest.net>.
Please also look at the Java2 APIs for HTTP support from inside servlets. Most
good servlet books cover http tunneling and things like cookies, session
management, authentication, PKI managed SSL support with JSSE is not as widely
documented yet but can be made to work.
It is NOT just XML all the way!
Serialized Java objects can be directly transmitted over http without platform
dependent prints. In addition, what Soap will provide is the option for a
consistent standard of an end to and interface. The XML based interface
definition will allow (eventually) true B2B, when the other requirements like
data privacy and security will be also satisfied. If we here do not find a
'generic' and open solution for the security issues, SOAP will not make it IMHO
and the Internet standard's body IETF will be open to billion dollar law suits.
Regards -George
Michael Brennan wrote:
> Here's another implementation question I have. (Again, I hope folks don't
> mind my asking.)
>
> The current HTTP protocol support seems very lightweight. What are the plans
> going forward? Any consideration of using third party HTTP lib? I've been
> looking, for instance, at the HTTP client library from the W3C included in
> the Jigsaw distribution. Rich support for HTTP/1.1 including authentication,
> cookies, chunked encoding, etc. Also has a very extensible architecture. For
> instance, the ability to attach filters that can modify requests or
> responses (this is how support for cookies, authentication, etc, is
> implemented). It seems like there is some reinventing of the wheel going on
> with the protocol support.
>
> I also noticed that the HTTPUtils.post method creates a PrintWriter for
> output on top of the output stream. That results in the local system default
> character encoding being used. Isn't this a bit dangerous? Shouldn't this be
> explicitly specifying, perhaps, a utf-8 encoding? Likewise with the Reader
> for reading the response.
>
> I'm very much a novice with SOAP and this implementation, so I apologize in
> advance if these are naive questions.
>
> Thanks.