-
Notifications
You must be signed in to change notification settings - Fork 59
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
Parsing problems? #34
Comments
Here is the log from parsing the debian-security URL
|
I am afraid this might have been a bug in v1.0.1. The idea is to open a link, and check if the response has
Another option is to detect content type, and classify everything with |
Really? Where does HTTPDirFS do this? I can't find any reference to this header in the code. What about /src/link.c#L48-L65 ? |
Yes, really. It is here: Perhaps this is not the smartest idea. Should I base the detection purely on the URL itself, rather than content length? Basically we have two ways of setting link type in two separate function. |
Well I don't know if it's smart or not, but it's definitely unexpected. I think perhaps by default we should detect whether a link is a directory by checking for a trailing slash on the HREF URL, since that seems to be the way most HTTP indexes work. What do you think? |
Yup, okay. I agree. Trailing slash definitely indicates a directory. I think I still need to keep the code to check whether a directory link is valid. I will patch it up in a few hours time :) - I need to go. |
Fixed in 78d8167 |
Since upgrading to 1.1.6 on Debian Buster I'm seeing problems which I think are related to index parsing. Now, with several pages, some directories are detected as files and vice-versa. See http://security-cdn.debian.org/debian-security/ for an example.
Also, for some directories, HTTPDirFS completely hangs in the background and its impossible to unmount the directory.
The same listings tested with version 1.0.1 work fine.
The text was updated successfully, but these errors were encountered: