-
-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support HTTP request method fallback #1327
Comments
That's a great idea! What counts as an error response? For connection errors, both methods shouldn't work. Currently, errors are defined as lychee/lychee-lib/src/types/status.rs Lines 159 to 164 in a8e9f04
where lychee/lychee-lib/src/types/status.rs Lines 22 to 43 in a8e9f04
and lychee/lychee-lib/src/types/error.rs Lines 12 to 148 in a8e9f04
Does that include all the cases we need to cover? I am wondering specifically about |
@sanmai-NL ping, in case you have any thoughts on this. |
I think your design makes sense. And if some adjustments turn out to be needed later, I don't expect those to have a high cost of change. |
Some misconfigured webservers don't accept HEAD requests, but using HEAD is more efficient and appropriate in general. As a rough but effective work-around, allow the configuration key
method
to be a list["head", "get"]
instead of a string, where Lychee's checking algorithm falls back to the subsequent HTTP method in the list if the former gives an error response. Regrettably, in practice the response codes returned upon HEAD requests by these misconfigured webservers vary (404, 403, etc.), so don't bother to implement a fallback condition evaluator.The text was updated successfully, but these errors were encountered: