RE: DO NOT REPLY [Bug 15741] - TCP Monitor does not handle WebD AV methods in proxy mode

[Doug Davis <du...@us.ibm.com>]

Huge +1 - that's what I do too.
-Dug


Tom Jordahl <to...@macromedia.com> on 01/06/2003 05:32:48 PM

Please respond to axis-dev@xml.apache.org

To:    "'axis-dev@xml.apache.org'" <ax...@xml.apache.org>
cc:
Subject:    RE: DO NOT REPLY [Bug 15741]  -  TCP Monitor does not handle
       WebD AV methods in proxy mode


> I tried out resend today after removing the content-length recalculation
and it
> works great, including with the s/w in proxy mode and multiple hosts in
the same
> TCP connection.

Wait a minute, the resend functionality needs to recalculate the
content-length again because you can edit the request before you send it.
This is how *I* use the resend button.

Please don't remove that code....


--
Tom Jordahl
Macromedia Server Development



-----Original Message-----
From: bugzilla@apache.org [mailto:bugzilla@apache.org]
Sent: Monday, January 06, 2003 5:23 PM
To: axis-dev@xml.apache.org
Subject: DO NOT REPLY [Bug 15741] - TCP Monitor does not handle WebDAV
methods in proxy mode


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15741>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15741

TCP Monitor does not handle WebDAV methods in proxy mode





------- Additional Comments From Christopher.D.Knight@nasa.gov  2003-01-06
22:22 -------
Of course! ;^) How about these test cases:

* running the latest Litmus (good HTTP + WebDAV test as well as a decent
stress
test) against TCPMon in listener mode. (Litmus should support proxies, oh
well.)
 See http://www.webdav.org/neon/litmus for details.

* doing some basic DAV interactions using the catacomb client against
TCPMon in
proxy mode.

* using an FTP client (in passive mode) and TCPMon in listen mode to try
some
non-plaintext/non-HTTP traffic.

* using "resend" in all of these cases.

I tried out resend today after removing the content-length recalculation
and it
works great, including with the s/w in proxy mode and multiple hosts in the
same
TCP connection.

Re: [Bug 15741] - TCP Monitor does not handle WebDAV methods in proxy mode

[Chris Knight <Ch...@nasa.gov>]

Doug Davis wrote:
> 
> Huge +1 - that's what I do too.
> -Dug
> 
> 
> Tom Jordahl <to...@macromedia.com> on 01/06/2003 05:32:48 PM
> 
> Please respond to axis-dev@xml.apache.org
> 
> To:    "'axis-dev@xml.apache.org'" <ax...@xml.apache.org>
> cc:
> Subject:    RE: DO NOT REPLY [Bug 15741]  -  TCP Monitor does not handle
>        WebD AV methods in proxy mode
> 
> 
> 
>>I tried out resend today after removing the content-length recalculation
> 
> and it
> 
>>works great, including with the s/w in proxy mode and multiple hosts in
> 
> the same
> 
>>TCP connection.
> 
> 
> Wait a minute, the resend functionality needs to recalculate the
> content-length again because you can edit the request before you send it.
> This is how *I* use the resend button.
> 
> Please don't remove that code....

Ah hah...Herein lies a much more complex problem. The current version of 
TCPMon does not distinguish between multiple HTTP requests in the same 
connection and should be fixed.

A couple ways to approach this (in no particular order of preference and 
noting the ease [likelyhood ;^o] of implementation):

* leave it the way it is and note that the content-length re-calculation 
is broken for multiple request connections, perhaps not allowing resend 
if there are multiple requests in the same connection. Not HTTP/1.1 
compliant. (VERY EASY)

* require hand-updating of the content-length, obviously difficult for 
users to use (VERY EASY)

* ensure that only one HTTP request can be edited at a time (HARD)

* try to determine where an HTTP request ends by looking for the next 
request method (although I would be loathe to hard-code any method names 
such as GET, PUT, POST, etc. as they're sure to change.) (HARD - what if 
an HTTP "request" is embedded in the body of a POST?)

* close the connection after the first HTTP response to ensure one 
request/connection. (EASY)

* when in "HTTP mode", have TCPMon separate individual 
requests/responses as if they were individual connections. Would prevent 
resending the entire request stream. (MODERATE)

* create a hierarchical structure of connections containing >= 1 
request/response pair. (HARD)

What is your opinion?

The bottom two are my preferences, but they're certainly a lot to tackle 
and I'd want to make sure that it would meet your needs and be adopted 
into the main distribution and hopefully get some help from someone who 
understands the code more than I.

As an aside, I'd like to be considered a Contributor (see 
http://jakarta.apache.org/site/roles.html) and as such I need to find 
out who the Committer is that I should coordinate with to get changes 
into CVS.  It might be worthwhile to have the list of Committers (or at 
least one) listed on the "Contacting Us" page.