Bug 54185 - Allow query strings in paths that start with HTTP or HTTPS
Allow query strings in paths that start with HTTP or HTTPS
Status: RESOLVED FIXED
Product: JMeter
Classification: Unclassified
Component: HTTP
2.7
PC All
: P2 enhancement (vote)
: ---
Assigned To: JMeter issues mailing list
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2012-11-21 19:05 UTC by Keith
Modified: 2012-11-22 13:37 UTC (History)
0 users



Attachments
Patch to allow query strings in paths starting with HTTP or HTTPS (990 bytes, patch)
2012-11-21 19:05 UTC, Keith
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Keith 2012-11-21 19:05:05 UTC
Created attachment 29620 [details]
Patch to allow query strings in paths starting with HTTP or HTTPS

I ran into a situation where an authorization server needed to have the default port for https included as part of the URL.  Since the default behaviour is to suppress default ports from being included in the generated URL I decided to leverage the behaviour of the path property to treat any path that starts with HTTP or HTTPS as the whole URL.  

Unfortunately this doesn't stop parseArguments() from being called.  The attached patch changes the behaviour to not call parseArguments if the path starts with HTTP or HTTPS (thus allowing query strings to be included as part of the "complete" URL as per the API - "As a special case, if the path starts with  http[s]://", then the path is assumed to be the entire URL.").
Comment 1 Sebb 2012-11-21 20:54:25 UTC
In the meantime, if you use the GUI to provide the full URL it will be used as is.

If you need to use a pre-processor to calculate the URL, just save it in a variable instead of using setProperty() and reference the variable in the GUI path field.
Comment 2 Sebb 2012-11-21 21:38:09 UTC
Patch slightly refactored and applied with Javadoc update:

URL: http://svn.apache.org/viewvc?rev=1412311&view=rev
Log:
Allow query strings in paths that start with HTTP or HTTPS
(so setPath behaves the same as if the path were set in the GUI)
Bugzilla Id: 54185

Modified:
    jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
    jmeter/trunk/xdocs/changes.xml
Comment 3 Keith 2012-11-22 12:58:03 UTC
(In reply to comment #1)
> In the meantime, if you use the GUI to provide the full URL it will be used
> as is.
> 
> If you need to use a pre-processor to calculate the URL, just save it in a
> variable instead of using setProperty() and reference the variable in the
> GUI path field.

The GUI option doesn't work which led to me making the patch:

If the port specified is the default port for a protocol (i.e. in my case HTTPS and port 443) then the sampler does not include the port in when it makes the request.

In my case the receiving server (which I have no control over) actually expects a URL with the following format:

https://domain:443/blah/SSO?qsStuff

I added https and 443 in the GUI, but my tests show that the request the sampler is making is:

https://domain/blah/SSO?qsStuff

Which the receiving server throws an internal error on.  

That's what led me to the path patch.  The other option I considered was a patch to allow "force port to be included in url", but it didn't seem as clean.
Comment 4 Sebb 2012-11-22 13:37:25 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > In the meantime, if you use the GUI to provide the full URL it will be used
> > as is.
> > 
> > If you need to use a pre-processor to calculate the URL, just save it in a
> > variable instead of using setProperty() and reference the variable in the
> > GUI path field.
> 
> The GUI option doesn't work which led to me making the patch:

Are you sure?
It works for me when tested with http: and 80.

However, it only works for the HC4 implementation.
It looks like the others omit the default port.

> If the port specified is the default port for a protocol (i.e. in my case
> HTTPS and port 443) then the sampler does not include the port in when it
> makes the request.
> 
> In my case the receiving server (which I have no control over) actually
> expects a URL with the following format:
> 
> https://domain:443/blah/SSO?qsStuff
> 
> I added https and 443 in the GUI, but my tests show that the request the
> sampler is making is:
> 
> https://domain/blah/SSO?qsStuff
> 
> Which the receiving server throws an internal error on.  
> 
> That's what led me to the path patch.  The other option I considered was a
> patch to allow "force port to be included in url", but it didn't seem as
> clean.

As far as I can tell, the only effect of the patch is to allow the path to be set to a complete URL programmatically; this is equivalent to setting it in the GUI (which sets the PATH property directly, bypassing the setPath() method).

The patch does not change how the path is used later.
So I don't see how the patch makes a difference, unless there is some other difference between the two tests.