I've never really felt very comfortable with tcpmon having an "http mode"
because I never really wanted it to know what the data was, I just wanted
it to be a dumb pass-thru. But, having the "xml filter" and having
"resend" do the recalc'ing of the content length header has sort of moved
us way past that point so we might was well go all the way. :-)
*If* we're going to know that we're dealing with HTTP then I like your idea
of tcpmon breaking each individual request/response pair into "something".
I don't like the idea "something" being new entries on the top listbox
since I do believe there is value in knowing which set of request/responses
were on the same socket. I really like your idea of creating a
"hierarchical structure of connections" where there's only one entry in the
top list box, but somewhere/somehow a 'sublist' is displayed of the
individual req/res pairs that went over that socket. That would be my vote
- but like you said, I think this is the hardest of the options. My next
choice would be to leave it as it is and just say resend is broken for
multiple connections.
So for becoming a committer I believe this will happen once you've offered
up enough patches.
-Dug
Chris Knight <[EMAIL PROTECTED]> on 01/07/2003 01:25:23 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: [Bug 15741] - TCP Monitor does not handle WebDAV methods in
proxy mode
Doug Davis wrote:
>
> Huge +1 - that's what I do too.
> -Dug
>
>
> Tom Jordahl <[EMAIL PROTECTED]> on 01/06/2003 05:32:48 PM
>
> Please respond to [EMAIL PROTECTED]
>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> 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.
