Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Message-ID: <051601c46d56$83736790$2e694109@LANKABOOK>
From: "Sanjiva Weerawarana" <sanjiva@opensource.lk>
To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
References: <20040719055104.59610.qmail@web40610.mail.yahoo.com>
Subject: Re: Implementation of SOAPTransport interface using LibWWW for client
Date: Mon, 19 Jul 2004 12:06:19 +0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I understand the principle, but is that a real feature in today's
Internet? For Web browsing it *may* make sense to have the *HTTP*
headers checked before the payload is sent (esp. if you have a
low bandwidth connection like I do), but even that is questionable
when payload for POSTs in HTTP is almost always very small.

For SOAP stuff, IMO it makes no sense. Why? Because most of the
time SOAP stuff will be unprocessable by the server because there's
something wrong in the *SOAP envelope* and not because there's anything
screwy with the HTTP headers. While whacky clients may use this HTTP
feature, in practice I don't see it being of any value in the SOAP
world.

I guess we should still support it because it could be an interop
problem, but if its too much of a pain I'd say let's not worry too
hard about it.

Keep-alive and chunking, OTOH, is very real and very useful to have.

Sanjiva.

----- Original Message ----- 
From: "Samisa Abeysinghe" <samisa_abeysinghe@yahoo.com>
To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Sent: Monday, July 19, 2004 11:51 AM
Subject: Re: Implementation of SOAPTransport interface using LibWWW for
client


> Using "Expect: 100-continue" header, your application safes time and
network (see RFC2616, section
> 8.2.3).
>
> Samisa...
>
> --- damitha kumarage <damitha@opensource.lk> wrote:
> > Well done Samisa,
> > What is this 100-continue?
> >
> > damitha
> > On Thu, 2004-07-15 at 17:27, Samisa Abeysinghe wrote:
> > > Hi All,
> > >
> > > I developed a transport module for clients using the trasport
> > > abstraction. I tested it on Linux and all seems to be fine except
> > > thread safety. The module need to be tested on WIndows.
> > >
> > > The Axis C++ server side fails to work with 100-continue. Axis Java is
> > > capable of managing 100-continue. This is the default mode used in
> > > LibWWW. I used a macro in Makefile.am to enable/disable 100-continue.
> > > (use -DHT_EXT_CONTINUE to enable or -UHT_EXT_CONTINUE to disable in
> > > AM_CPPFLAGS setting) I observed that the transport is much faster when
> > > it is used without 100-continue. However, to disable 100-continue,
> > > LibWWW need to be built with -?with-extension option (./configure
> > > --with-extension)
> > >
> > > You do not need to bother about location of LibWWW headers and
> > > libraries, provided that you have done the LibWWW installation
> > > properly. I have used libwww-config in the Makefile.am to pick LibWWW
> > > specific settings.
> > >
> > > Once you build the library, you could use it by specifying the
> > > location of the lib in $AXIS_HOME/axiscpp.conf file.
> > >
> > > e.g.Transport_http:/usr/local/Axis/libs/libaxis_LibWWWTransport.so
> > >
> > > For more information on LibWWW please see
> > > http://www.w3.org/Library/User/
> > >
> > > Issues:
> > >
> > > The thread test in tests/client/threadSafe fails with this
> > > implementation. Bit of surfing lead me to
> > > http://www.w3.org/Library/User/Architecture/Events.html, which says
> > > "LibWWW is not posix thread safe but it uses a 'pseudo-thread' model
> > > based on non-blocking sockets and interleaved IO." Bit of research is
> > > needed to figure out how to make this implementation thread safe. It
> > > remains a TODO as of now.
> > >
> > > Thanks,
> > >
> > > Samisa...
> > >
> > >
> > > ______________________________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Mail is new and improved - Check it out!
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
> http://advision.webevents.yahoo.com/yahoo/votelifeengine/
>
>