fix: resolve index file inside a directory#1752
Conversation
| // If path is a directory, and we cannot find an index file inside it, | ||
| // and we don't have a fragment, just return success. This is for | ||
| // backward compatibility. | ||
| else if path.is_dir() && !has_fragment { | ||
| return Status::Ok(StatusCode::OK); |
There was a problem hiding this comment.
I added this logic to ensure that the following test can pass:
lychee/fixtures/fragments/file1.md
Lines 68 to 70 in 8f2f746
While I personally prefer this test to fail, I may not be aware of all the context surrounding it.
There was a problem hiding this comment.
I just found that I forgot to add the fragment to this test case. So it doesn't test the new code in #1713.
Instead, it has been treated as a success by lychee for a long time.
I'm not sure whether it's a common case for some scenarios or not.
There was a problem hiding this comment.
@kemingy Hey 👋
If I take out the quoted code in this comment, in other words, treat [empty](empty_dir/#no_exist_fragment) as an error, will this cause the "Too many open files" error to reappear? I'm not entirely clear on how checking link fragments relates to the "Too many open files" error.
There was a problem hiding this comment.
No. I think it's safe to treat the empty_dir#fragment as an error.
There was a problem hiding this comment.
Nice! I'll keep this PR as it is to limit its scope. I'll open another PR to make empty_dir#fragment an error.
|
Fantastic. That should work! |
Yes, much appreciated. |
|
3 participants
Closes #1751
This PR addresses issue #1751 by adding an "index" file check logic into Lychee. When the URL points to a local directory, it attempts to locate the index file within that directory and verify its fragments.