https://issues.apache.org/bugzilla/show_bug.cgi?id=54185
--- Comment #4 from Sebb <[email protected]> --- (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. -- You are receiving this mail because: You are the assignee for the bug.
