Odd redirects caused by bombardier appending the default port to the request URLs, when the original URL for testing had none

[codesenberg]

Previous discussion

Originally posted by @amir20 in #93 (comment)

That's the issue. Both curl and http are showing normal output.

See below...

❯ bombardier https://www.clashleaders.com/
Bombarding https://www.clashleaders.com:443/ for 10s using 125 connection(s)
[================================================================================================================================================] 10s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec        50.94     491.65    5714.64
  Latency         1.98s   394.55ms      4.00s
  HTTP codes:
    1xx - 0, 2xx - 0, 3xx - 50, 4xx - 0, 5xx - 0
    others - 585
  Errors:
    tls handshake timed out - 585
  Throughput:    21.19KB/s

❯ curl -I https://www.clashleaders.com/
HTTP/2 200
content-type: text/html; charset=utf-8
date: Sun, 28 May 2023 19:21:09 GMT
set-cookie: csrf_token=IjgyYjM0MDY1MGM1NWRhOWM4ZjA0NDAwZDMzODIwMTRmNjExNTdjZDEi.ZHOppQ.uBOUb9omEriMgcmph31pRfoMGHo; Path=/
set-cookie: session=eyJjc3JmX3Rva2VuIjoiODJiMzQwNjUwYzU1ZGE5YzhmMDQ0MDBkMzM4MjAxNGY2MTE1N2NkMSJ9.ZHOppQ.ciOQwlMUxib7t5csKf5z5u3xmUE; HttpOnly; Path=/; SameSite=Lax
strict-transport-security: max-age=315360000; preload
vary: Cookie
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1; mode=block
content-length: 49160

Ideally, I'd like to see what is causing the 3xx requests but I haven't been able to figure it out.

I am guessing something with SSL handshake.

Same errors with --http2 and --http1

Originally posted by @codesenberg in #93 (comment)

I am guessing something with SSL handshake.

Nope. Actually, it's just 301 in case of this site. Not sure why would they redirect to the exact same location, but that's a different issue. In case you need further assistance file a separate issue, since this one is for the general feature discussion, not to troubleshoot oddness like the one you've encountered.

Originally posted by @amir20 in #93 (comment)

Thanks. I am the owner of https://www.clashleaders.com/. I don't send any 301 redirects. But that's ok. I was just testing this tool.

Resolution

I think this is something DigitalOcean (where I assume www.clashleaders.com is hosted) or your nginx (or some other HTTP server) is doing for you.
It was caused by bombardier appending default port to the URLs used for requests sent, if one wasn't provided. This should be fixed in fcd960d. Example output using master:

$ bombardier -c10 https://www.clashleaders.com/
Bombarding https://www.clashleaders.com/ for 10s using 10 connection(s)
[========================================================================] 10s 
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec        48.81      44.77     343.18
  Latency      210.73ms   136.47ms      1.20s
  HTTP codes:
    1xx - 0, 2xx - 479, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:     2.26MB/s

[amir20]

Thanks! Still not getting the fix with go install github.com/codesenberg/bombardier@latest

I don't use nginx. Proxy is done with docker and in front of it sits a traefik instance that handles all the SSL. Maybe that's the issue.

[codesenberg]

Thanks! Still not getting the fix with go install github.com/codesenberg/bombardier@latest

That's because @latest actually means:

(“Latest” is defined as the latest tagged stable (non-[prerelease](https://semver.org/#spec-item-9)) version,
or else the latest tagged prerelease version, or else the latest untagged version.)

from https://go.dev/blog/using-go-modules

For bombardier latest tagged stable version is v1.2.6, which doesn't contain the fix.

Instead, you probably want to run go install github.com/codesenberg/bombardier@master, which will fetch whatever currently is in the master branch.

[amir20]

Confirmed it works. Thank you!