[OpenSTA-devel] [ opensta-Bugs-1389081 ] Gateway does not munge HTTPS URLs in CSS content

[SourceForge.net <no...@so...>]

Bugs item #1389081, was opened at 2005-12-23 13:56
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1389081&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Behavioral
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Gateway does not munge HTTPS URLs in CSS content

Initial Comment:
While recording HTTPS traffic the gateway must
translate all HTTPS URLs in the content returned to the
client being recorded to be http://{ - this is to stop
the client attempting to make SSL/TLS connections to
the Gateway which cannot be recorded and will stop the
halt the gateway.  You can see this happen if you have
a "Unsupported protocol ..." comment in your created
script and your recording browser stops being able to
access any site.

In the OpenSTA 1.4.3 release and earlier the only
content they had this munging done was HTML and
javascript.  The most obvious other type of content
that may need munging is CSS ... but there may be others.

----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2007-07-03 16:25

Message:
Logged In: YES 
user_id=19748
Originator: YES

A fix for this issue has been merged into the CVS HEAD.  It
will become generally available in the OpenSTA 1.4.4 release.
gwhttp.dll: 1.4.4.4
OpenSTA: 1.4.4.6

This fix specifically adds checking of CSS to the list of content
types that are checked and munged for HTTPS.  A better solution
would be to allow the list of content-types that are checked and
munged to be user specifiable ... but given the apparent longevity
of the Gateway HTTPS recording solution, it seems pointless to put
any more effort in than this hard coded solution.  The code was
reworked to make it easier to add compiled in content-types though. 

----------------------------------------------------------------------

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-12-23 14:42

Message:
Logged In: YES 
user_id=19748

A possible workaround for this problem is to use the
Remote(manual) recording method and not specify any proxy
for HTTPS content.  This obviously means that the failure
case requests will not be recorded but it may at least allow
some people to make partial recordings of their sites, to
which they can add the problem requests later.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1389081&group_id=10857