Mansfield mansfield at ondollo.com
Tue Jan 26 02:36:14 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Sun, Jan 24, 2021 at 7:23 PM Sean Conner <sean at conman.org> wrote:
It was thus said that the Great Mansfield once stated:
All,
Hopefully the first of several announcements this week:
We would like to share a public HTTP proxy for Gemini Space.
Please find it at https://gem.ondollo.com/
We've worked hard to make the HTML/CSS clean and small.
Enjoy!
Okay, I ran it through the Client Torture Test. You had possible
problems
with tests 34 through 38 where the first digit was defined, but not the
second digit (you treated them all as errors). In my mind, to future proof
the client, just treat any unknown second digit as '0' (so 29 is 20, 39 is
30, etc). But hey, another unpainted bikeshed here!
Good to know... I took a different approach with an unknown second digit asyou saw. I went back and re-read the spec... I couldn't find clear guidanceeither way. In my mind it was better to be strict so that unknown statuscodes wouldn't result in something unintended. To me a 29 isn't a 20... butthe spec does say that clients can exist without knowledge of the seconddigit in a status code... I'll have to think about this some more.
Also, your client doesn't handle the following link properly:
gemini://gemini.conman.org/test/UCSD-Pascal-source.zip/
It strips off the final '/', which does The Wrong Thing in this case (yes,
the final '/' is significant). Speaking of which, you don't handle MIME
types properly---the page through your proxy tried printing the resulting
ZIP file as text. I have a few other pages that return non "text/*" MIME
files.
Humm... the CLI version (that uses the same library) didn't fail on thatlink. I think the intent is to get a directory listing of the contentinside the zip file, right? I'll have to walk through the code specificallyfor that to see where it went wrong. Thanks for writing those tests.
Mime--types... yeah. I'll add that in.
It also sends a client certificate. Unexpected, but something I think
people should be aware of.
-spc
True. The client code underneath the HTTP handler always sends acertificate when it makes the Gemini call. It's the same certificate forevery call, so there's nothing leaking from the users browser into thecertificate. Was that the concern?
Thanks for your feedback!-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210125/e428f2f7/attachment.htm>