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.").

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.

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

(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.

(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.

This is ASF Bugzilla: the Apache Software Foundation bug system. In case
of problems with the functioning of ASF Bugzilla, please contact
bugzilla-admin@apache.org.
Please Note: this e-mail address is only for reporting problems
with ASF Bugzilla. Mail about any other subject will be silently
ignored.