Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: An extention for MaxQ

maxq
Discussion topic

Hide all messages in topic

All messages in topic

Re: An extention for MaxQ

Author oliverbock
Full name Oliver Bock
Date 2006-04-05 00:54:39 PDT
Message Bruno Dillenseger wrote:
>> I think it makes sense for the delay information to be available for all
>> generators, so I think it should be included in the main part of MaxQ.
>> Non-ISAC generators can ignore this information, at least for now.
>> (Perhaps later they will include it in a comment.) As to whether the
>> HTTP headers are a good place to get the information, I do not know what
>> is available there. Why would this more complicated approach be
>> superior to simply using the system clock? If the test uses more than
>> one computer you may have problems with unsynchronised clocks or clocks
>> in different time zones.
>>
> Yes. Probably it would be better to include date information (from the
> proxy local system clock) in the script generation interface.
> It probably requires to modify something in what you call "the main
> part" of MaxQ. How do you evaluate the amount of work for this
> enhancement?
There are too many unknowns for me to put a number on it, but I would
call it "easy to medium" as it will require some understanding of MaxQ's
recording internals, and simple modification to all generators.


  Oliver

Re: An extention for MaxQ

Author oliverbock
Full name Oliver Bock
Date 2006-04-04 15:36:50 PDT
Message Hi Olivier et François,

I think it makes sense for the delay information to be available for all
generators, so I think it should be included in the main part of MaxQ.
Non-ISAC generators can ignore this information, at least for now.
(Perhaps later they will include it in a comment.) As to whether the
HTTP headers are a good place to get the information, I do not know what
is available there. Why would this more complicated approach be
superior to simply using the system clock? If the test uses more than
one computer you may have problems with unsynchronised clocks or clocks
in different time zones.

I think that using a configuration file for ISAC settings is a good
idea, although a dialog box would also be OK. Can I suggest that you
add ISAC-specific settings to maxq.properties rather than creating a new
configuration file? It may be difficult to clearly delineate properties
that relate to MaxQ versus properties that relate to ISAC. You will
presumably use maxq.properties to select your ISAC generator, so perhaps
it makes sense to also specify the ISAC plugin there. It also reduces
the number of files and the complexity of the configuration code. (i.e.
you can simply add some new settings to Config.java.) However I do not
feel strongly about this and would not be bothered if you preferred a
separate file.


  Oliver

--
Olivier Lecrivain wrote:
> We are currently working on the ISAC code generator. In ISAC scenario,
> we need to specify a delay between each request and it seems that the
> current HttpHeaderRequest doesn't extract the date from the headers.
>
> We think we have two ways to fix this. On one hand we could keep the
> time between each request in our generator. On the other hand we could
> enhance HttpHeaderRequest, making it records the date from the headers
> and calculate the delay between two requests by substracting their
> date. Can we have your advice on this point?
>
> In addition, we need to configure how our generator records the
> requests (for example we can choose which ISAC plugin to use). We
> think that adding an options window in the GUI would be a bit tricky.
> Are you ok if we add a property file in the conf directory which will
> do this configuration work?
>
> Best regards,
>
> Olivier Lecrivain, François Vinassac
>
>
> On 3/31/06, *Oliver Bock* <oliver at g7 dot org <mailto:oliver@g7​.org>> wrote:
>
> On 31/03/2006, at 18:16, Bruno Dillenseger wrote:
>> Encryption is inherent to HTTPS and so you are right in
>> considering that the proxy approach looks like a man-in-the-middle.
>> We could consider the way OpenSTA's capture proxy solves this
>> problem, by changing https://... URIs to http://{... URIs and
>> having the proxy manage the HTTPS protocol with the server and
>> record whatever necessary without encryption problem.
>> See:
>> http://portal.openst​a.org/modules.php?op​=modload&name=ph​pWiki&file=index​&pagename=Record​ingHttps
>> <http://portal.openst​a.org/modules.php?op​=modload&name=ph​pWiki&file=index​&pagename=Record​ingHttps>
>> http://portal.openst​a.org/modules.php?op​=modload&name=Ne​ws&file=article​&sid=5
>> <http://portal.openst​a.org/modules.php?op​=modload&name=Ne​ws&file=article​&sid=5>
>>
>> So, to sum up:
>> - probably there is nothing to change about MaxQ (we just have to
>> check the abstract script generation interface),
>> - HTTPS support could probably be introduced, based for instance
>> on OpenSTA's trick.
>
> Having read all the text required to explain the http://{ trick,
> and read about the IE bug, and considered that it won't solve URLs
> embedded in CSS files, JavaScript or other client-side
> technologies, I think that the solution they rejected is superior:
> MaxQ should be man-in-the-middle. The cost is a single warning at
> the start of recording. In exchange we get reliable recording
> that requires little explanation.
>
>
> Oliver
>
>

Re: An extention for MaxQ

Author oliverbock
Full name Oliver Bock
Date 2006-03-31 01:25:02 PST
Message On 31/03/2006, at 18:16, Bruno Dillenseger wrote:
> Encryption is inherent to HTTPS and so you are right in considering
> that the proxy approach looks like a man-in-the-middle.
> We could consider the way OpenSTA's capture proxy solves this
> problem, by changing https://... URIs to http://{... URIs and
> having the proxy manage the HTTPS protocol with the server and
> record whatever necessary without encryption problem.
> See:
> http://portal.openst​a.org/modules.php?
> op=modload&name=​phpWiki&file=ind​ex&pagename=Reco​rdingHttps
> http://portal.openst​a.org/modules.php?
> op=modload&name=​News&file=articl​e&sid=5
>
> So, to sum up:
> - probably there is nothing to change about MaxQ (we just have to
> check the abstract script generation interface),
> - HTTPS support could probably be introduced, based for instance on
> OpenSTA's trick.

Having read all the text required to explain the http://{ trick, and
read about the IE bug, and considered that it won't solve URLs
embedded in CSS files, JavaScript or other client-side technologies,
I think that the solution they rejected is superior: MaxQ should be
man-in-the-middle. The cost is a single warning at the start of
recording. In exchange we get reliable recording that requires
little explanation.


    Oliver
Attachments

Re: An extention for MaxQ

Author oliverbock
Full name Oliver Bock
Date 2006-03-30 14:33:50 PST
Message Dear Bruno and François,

Yes, as luck would have it, MaxQ already includes an abstract script
generation interface, which is used to produce two types of Jython
scripts and plain Java scripts (not maintained).

Overall my only concern with contributions is that they don't break
existing functionality and don't needlessly complicate the structure of
the MaxQ code. New script generators will not cause problems, and the
other suggestions you have (cookie recording and HTTPS support) would
benefit all MaxQ users.

MaxQ does not currently _record_ cookies, but it handles them correctly
during playback, treating all cookies as session cookies.

Because MaxQ needs to see the content of any HTTPS stream it proxies, I
suspect that HTTPS will be a bit tricky. (You would be making a "man in
the middle" attack on the encryption.) Perhaps this will be OK if the
users recording are willing to ignore warnings from their browsers.

I have CC'd this message to the MaxQ dev mailing list because I think
your query is of general interest. I would prefer to continue this
discussion there for the benefit of other contributors (quiet though
they may be).


Regards,

   Oliver

--
Bruno Dillenseger wrote:
> Hello,
>
> As CLIF project leader, I confirm that we are looking for some open
> source HTTP proxy in Java to reuse and adapt as a web session recorder.
> The thing is that we want to produce scripts with a CLIF specific
> format (ISAC XML format).
>
> According to Francois and Olivier, your code would be the best for our
> target.
>
> I must confess that I did not see your code yet, but the way I see
> things could be done would consist in defining a generic script
> generation interface in order to abstract the capture itself from the
> actual script generation in a target language (currently Python). This
> would make your project easily reusable by many projects, such as CLIF
> that would provide an ISAC script generator. But probably this
> interface already exists?
>
> Of course, Olivier and Francois would contribute to the job with my
> support, as well as your agreement, supervision and support. We'd
> rather contribute to your project instead of duplicating it somewhere
> and building a parallel branch in CLIF project. Our target is to have
> support for cookies and hopefully HTTPS.
>
> To conclude with this request, please note that Olivier and Francois
> will end this work by the end of April... so things should be decided
> ASAP.
>
> Best regards,
> -- Bruno.
>
> Le jeudi 30 mars 2006 à 17:00 +0200, François Vinassac a écrit :
>> Hello,
>>
>> we are 2 students working on a web session recorder for the CLIF project
>> ( http://clif.objectweb.org/ ), a ObjectWeb Consortium project.
>>
>> The purpose of our work is to capture HTTP requests of a
>> web session in order to generate an ISAC scenario,
>> which can be replayed by the CLIF injector.
>>
>> Would you agree to integrate our generator in your project ? Also we
>> guess if your proxy is able to record cookies. If not, we will have to
>> modify your HttpRequestHeader class to support them. Would you
>> accept those contributions ?
>>
>> We are really interested in your project and we hope a positive
>> response.
>>
>> Best regards,
>> François Vinassac
>>
Messages per page: