| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
previously, the fragment was sent in the request from client, and the
server would parse and increment its value. the incremented value would
be set in the redirected URI.
this does not work as fragments are meaningless to servers and clients
like check_curl strip them in their GET request.
rewrite the fragment handling . if client sends a URI parameter with
'fragment' as its key, the server will set its value for its redirected
URI. it will come up both as a parameter and the fragment at the end.
use this new logic to rewrite the fragment redirection test. remove -p
$http_port argument on tests for this endpoint, which was making https
tests fail. correct the common test count from 75 to 95, as there are 20
total test assertions in the 8 times it uses the new endpoint. remove
unused code on that endpoint as well
|
|
use the parameters in the last redirected URI that that server returns
HTTP OK to. matches the incrementation count of redirection_count from 0
to 3, as they also get incremented three times alongside it. add
comments about what is happening in the test cases, no need to
understand the endpoint completely
|
|
|
|
plugins/tests/check_curl.t forks and runs a http(s) server that responds
to specific uri endpoints. Added another endpoint under
/redirect_with_increment with dynamic redirection points.
This endpoint will parse different parts of the uri that come after the
path: parameters, query and the fragment. If applicable, seperate
elements within each field are parsed into key/value pairs. value is
incremented in redirected URI.
Tests if check_url redirection logic retains different parts of the url
when parsing the uri and building the new redirected URL. Current tests
show that it ignores the fragment part.
|
|
|
|
|
|
Having a webserver respond with a relative redirect as for ex. in `Location: /path/to.html`
check_curl would use the wrong standard http/https port instead
of crafting the absolute url using the given scheme/hostname and port.
Adding a new test case for this for check_http and check_curl. check_http did
it correct already, so no fix necessary there.
before:
%>./check_curl -H 127.0.0.1 -p 50493 -f follow -u /redirect_rel -s redirected -vvv
**** HEADER ****
HTTP/1.1 302 Found
...
Location: /redirect2
...
* Seen redirect location /redirect2
** scheme: (null)
** host: (null)
** port: (null)
** path: /redirect2
Redirection to http://127.0.0.1:80/redirect2
fixed:
%>./check_curl -H 127.0.0.1 -p 50493 -f follow -u /redirect_rel -s redirected -vvv
**** HEADER ****
HTTP/1.1 302 Found
...
Location: /redirect2
...
* Seen redirect location /redirect2
** scheme: (null)
** host: (null)
** port: (null)
** path: /redirect2
Redirection to http://127.0.0.1:50493/redirect2
Signed-off-by: Sven Nierlein <sven@nierlein.de>
|
|
|
|
|
|
|
|
sslutils used to load only the first certificate when it was given a
client certificate file.
Added tests for check_http to connect to a http server that expects a
client certificate (simple and with chain).
Signed-off-by: Tobias Wiese <tobias@tobiaswiese.com>
|
|
github action might fail from to time otherwise
|
|
check_curl crashes when a (broken) http server returns invalid http header with
leading spaces or double colons. This PR adds a fix and a test case for this.
Signed-off-by: Sven Nierlein <sven@nierlein.de>
|
|
the example certificate has changed since.
|
|
|
|
|
|
handling empty data in POST and PUT
handling data upload (from -P <postdata>) also in PUT
|
|
slightly
|
|
|
