Re: get body of a response

Wang, Xinju [mailto:Xinju.Wang@ugs.com] wrote:

> In HTTP.c, I changed the code to treat 207 the same
> as 200 and I can get the response body back! It turns
> out that before the change, the library thinks 207 as
> a failure and wipe out the output stream buffer.

This sounds like pretty much the same experiences I
had, with the same fixes.

> For the request body, I tried the approach mentioned
> in your discussions with Josh Watts: add a new data
> field char* body in _HTRequest, and in the
> HTTPGen_new() in HTTPGen.c, send the body through when
> the  body is not NULL. And it worked.

> Did Josh check in his change?

I don't think he did, but I don't know for sure.

> I also tried to add a extension method to libwww. The
> idea is this generic function lets user specify the
> method, headers, url, and body of a request and send
> the request over the network. 

This sounds like a very good idea.  Hacking enums in
header files to get in new methods for webdav, didn't
feel like a very scalable approach...:-)

Have you run into any problems where the library
internally treat methods as bitmasks (also in my
archived discussions with Josh Watts)?

> The user should know what he's doing by using this
> function. It should look like:

> void ExtensionMethod(HTMethod method, char* url, char* body, 
> HTAssocList*
> headers, HTResponse* response);

Hm... HTMethod is an enum, no...?
	<http://www.w3c.org/Library/src/HTMethod.html>

What will you put in the method argument?  An integer 
value not in the enum?  A new value in the enum, saying 
that this is an extension value?

> So the user doesn't have to write a new function
> whenever new methods been added to extend HTTP. Will
> this have any side effects? 

It's possible that stuff in libwww treat method values
as bitmasks, but I don't know this for sure.  That could
be a complication.  And it also limits the possible
number of simultanous methods, at least if you're
sticking inside a 32 bit limit.

























This email, its content and any attachments is PRIVATE AND CONFIDENTIAL to
TANDBERG Television. If received in error please notify the sender and
destroy the original message and attachments.

Received on Tuesday, 13 November 2001 02:17:39 UTC