Molly sending empty mime type #8
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
** Duplicate of this issue for AV-98 **
I was unsure if molly-brown supported cgi currently or not. So I decided to make a cgi folder in my user folder on rawtext.club and added a simple python script:
gemini://rawtext.club/~sloum/cgi/test. All the script does is print40 The script works\r\nto stdout (I did an error code as a part of my debugging this issue, it had formerly been a 20).AV-98 and Bombadillo both have issues with visiting that link. They do not receive the above message. Instead they receive:
20 \r\n. My guess is that this is because molly does not support cgi (at least in the way I was trying, but I could find no docs ont he subject... though the code looks like it is supported - I know we've talked about it but I forget).I believe what is happening is that molly does not supply a mime if none can be discerned. This means that the response header was likely: 20 \r\n. Neither of our clients like that response. Molly should get updated to deal with an empty mime (the file
testgives no hint as to its type without looking at a shebang, which I guess the go mime library does not do). I would suggest returning text/plain when a mime cannot be discerned.As an added note. If I add
.txtto the file (which is set to755for its perms) I get20 text/plain\r\nas the header returned from the server and I get the contents of the python file.CGI works when you create a folder called
cgi-bin(can be configured in molly.conf) in your root and put executable files in there which prints the gemini header (20 text/plain\r\n) and the text to stdout. Be aware that molly-brown does not fix ends of line, so simple bash script using echo will not work, you will have to fix the ends of line manually. This bug is not related to CGI, because molly doesn't consider files incgi/a cgi script by default.I think that, as per Issue #5, what's going on here is that the script isn't being run at all.
However, you've found a genuine bug here - Molly tries to guess MIME types from file extensions, and it looks like when there's no exception the result is a "20 \r\n" header, which is not guaranteed to be appropriate.
Not only is it a bug that Molly sends this, but it's a bug that AV-98 and Bombadillo choke on it! The spec does explicitly say that if a status 2x response has no then it should default to "text/gemini; charset=utf-8". Failures all round. :)
I'm going away for a few days tomorrow and will be relaxing off grid the whole time. When I get back, I have some vacation time off work and hope to do a lot of work on both AV-98 and Molly Brown in that time. I'll address this and all other recent Issues then.
Now I'm a little confused, it looks like the issue with empty MIME types was actually fixed 3 weeks ago:
532dd83414Sloum, were you running an older build when you had this problem? If not it's possible there is an alternate code path that still serves an empty MIME type.
This came up on rawtext.club and I believe he is running an older build there. So if it has been resolved by a semi-recent PR I think it is probably solid. I know cmccabe was planning on upgrading to the newest version (in an attempt to solve the cgi issues we are having) and I can verify that this is fixed at that time and add a comment here once I do so. ????
I'll close this because I'm pretty sure Molly doesn't do this anymore and hasn't for a while, but feel free to reopen it if you ever see evidence otherwise.
The corresponding AV-98 issue is still relevant, though, and I'll leave that open until I fix it.
Sounds good. I fixed Bombadillo (in an as of yet unreleased branch) to default to
text/geminiwhen a mime is not provided, so I probably wouldnt have noticed the fix. Glad it got worked out though :)