[ANN] Public HTTP Proxy at gem.ondollo.com
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
> 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 as
you saw. I went back and re-read the spec... I couldn't find clear guidance
either way. In my mind it was better to be strict so that unknown status
codes wouldn't result in something unintended. To me a 29 isn't a 20... but
the spec does say that clients can exist without knowledge of the second
digit in a status code... I'll have to think about this some more.
> Also, your client doesn't handle the following link properly:
> 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
Humm... the CLI version (that uses the same library) didn't fail on that
link. I think the intent is to get a directory listing of the content
inside the zip file, right? I'll have to walk through the code specifically
for 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.
True. The client code underneath the HTTP handler always sends a
certificate when it makes the Gemini call. It's the same certificate for
every call, so there's nothing leaking from the users browser into the
certificate. Was that the concern?
Thanks for your feedback!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gemini