gemini+submit:// (was Re: Uploading Gemini content)

On 16-Jun-2020 02:37, Sean Conner wrote:
> It was thus said that the Great Pete D. once stated:
>> And so now, seeing all this wiki talk, I'm excited again by the idea of a
>> wiki protocol, but at the same time, I feel like it really should be a
>> different project. It's not what gemini is.
>>
>    Sadly, that *is* HTTP.  HTTP/1.0 added the methods PUT and DELETE which
> make adding/updating/removing resources from a webserver possible with just
> a web client.  The methods map to:
>
> 	GET	Retrieve a resource, should be no side-effects on the server
> 	POST	Submit data to an existing resource
> 	PUT	Add a new resource (a file for example) to the server
> 	DELETE	Remove a resource (a file for example file) from the server
>
>    The major difference between POST and PUT is that with POST, the resource
> receiving the data isn't modified (it's a fixed endpoint) whereas with PUT,
> the resource given is created or modified by the data.

Yes at the moment we have implemented GET, but not POST. It turned out 
the other verbs (PUT, DELETE) are not really essential as they can 
usually be implemented via POST, certainly for user facing applications. 
So I don't think there is a need to get side tracked by those.

As far as I understand it GET is supposed to be for persistent resources 
that are more or less idempotent. It shouldn't really be used as a 
vehicle to update a system, as the URLs are shareable and linkable 
(hence the potential SPAM problem of having a million pre-configured 
links to post comments whenever a search engine crawls your page).

Unfortunately we don't have any equivalent to POST. I do think this is a 
weakness and would be pleased to understand what the alternative in-band 
method is. SSH and SFTP is I know being recommended for some, but a) 
that is an out of band channel and wont be accessible to the majority of 
end users and b) limits the content to being file-system based.

We should not re-implement the web I agree, but there are a few things 
we should learn from that history and specify a constrained POST scheme 
that is not extendible.

>    Of the complaints I've read online about Gemini, the question of "why not
> use HTTP" comes up, and in a sense, I can see the reason for the
> question---HTTP does *not* inherenetly imply spying and tracking but that
> there are external forces that force that in the HTTP world.
>
>    I still like the idea, but the trick is to tame (or limit) the damage that
> can be done.

I think we just need to lock it down and keep it really simple, but good 
enough. Something like this:

scheme://domain/fixed-end-point?params
<here come the bytes...>
close connection

params should include path/content length/mime but not the content

We just need to bolt it down. There should be no _hidden_ state that the 
server can request (like cookies).

Seeing as gemini just does GET, we can have a single simple POST scheme 
that does nothing else

gemini:// (a perfect simple GET, not really extendible)
postscheme:// (a perfect simple POST, not really extendible)

Maybe in future PUT/DELETE but I dont think they're needed as a suitably 
configured end point can receive parameters to enact this. The web got 
by without it for almost all of its life, and is only used by some REST 
end points.

Best Wishes

  - Luke