CGI

[Paul Boyd]

I put all the collected data in the URL. It works pretty well and got rid
of the temp files. It event fixed the cache problem since each generated
URL is unique to the data submitted. But it generates some nasty URLs (see
the bottom).

Luke, good points about the ability to replay a post. Temporary session
files didn't have that problem at least. I suppose I could bring back a
session ID just to counter replays, but I'll wait until it becomes a
problem.

Anyway, I'm probably not going to write something like this again. The
guestbook is kind of fun (Hello Kévin and Timur!), so I'll leave it up. But
I'll stick to things that fit better in the future.

Case in point about replays, here's an ugly URL to a pre-filled form:

gemini://
pboyd.io/cgi-bin/guestbook.pl/link/S2luZyBBcnRodXI=;Q2FtZWxvdA==;VGhlIExhZHkgb2YgdGhlIExha2UsIGhlciBhcm0gY2xhZCBpbiB0aGUgcHVyZXN0LCBzaGltbWVyaW5nIHNhbWl0ZSwgaGVsZCBhbG9mdCBFeGNhbGlidXIgZnJvbSB0aGUgYm9zb20gb2YgdGhlIHdhdGVyIHNpZ25pZnlpbmcgYnkgRGl2aW5lIFByb3ZpZGVuY2UgdGhhdCBJLCBBcnRodXIsIHdhcyB0byBjYXJyeSBFeGNhbGlidXIuIFRoYXQgaXMgd2h5IEkgYW0geW91ciBraW5nIQ==;?none

Paul

On Fri, Jul 17, 2020 at 2:59 PM Luke Emmet <luke at marmaladefoo.com> wrote:

> A word of warning - as you probably have surmised, query string or
> otherwise manipulated URLs are not good for all types of application.
> They work just like HTTP GET queries and as such should really be
> limited to idempotent interactions with the server (like search queries
> or other peristent URLs).
>
> There is nothing yet equivalent to a non-cacheable data submission to
> the server (like HTTP POST) yet. I think it would be great if there
> could be one, but nothing on the horizon at the moment.
>
> So the complex URLs you can assemble in interactions with Gemini are
> subject to being linked to and replayed.
>
> For example if I have a page on my site with 100 parametrised links to a
> gemini based guest book, every time GUS comes to visit, there could end
> up being 100 new entries posted!
>
> Best wishes
>
>   - Luke
>
> On 17-Jul-2020 19:26, Paul Boyd wrote:
> > Hmm.. interesting. I'm already packing data into the URL path, so
> > yeah, I can just put the rest of the data in there. I'll have to try
> > it out when I get a minute.
> >
> > The protocol spec has a max URL size of 1024 bytes, but as long as the
> > inputs are short I think it will work.
> >
> > Paul
> >
> > On Fri, Jul 17, 2020 at 1:37 PM Michael Lazar
> > <lazar.michael22 at gmail.com <mailto:lazar.michael22 at gmail.com>> wrote:
> >
> >     I like the form idea and I wrote something similar for gopher a
> >     while back [0].
> >
> >
> https://gopher.floodgap.com/gopher/gw?=mozz.us+7005+312f64656d6f2d666f726d
> >
> >     In my case, I used URL query parameters to keep track of
> >     previously submitted
> >     form values. This worked because query params do not have any
> >     special meaning
> >     in gopher URLs. For gemini the query component is reserved, but
> >     you could
> >     probably accomplish the same thing using a special path component
> >     with the
> >     encoded fields in it.
> >
> >     gemini://example.com/cgi-bin/form/name%3Dpaul%26location%3Dcanada/
> >     <http://example.com/cgi-bin/form/name%3Dpaul%26location%3Dcanada/>
> >
> >     - mozz
> >
> >     [0]
> >
> https://github.com/michael-lazar/flask-gopher/blob/master/demo/run_server.py#L154
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200718/9399e640/attachment.htm>