gemini+submit:// (was Re: Uploading Gemini content)
- 🗣️ From: Luke Emmet (luke (a) marmaladefoo.com)
- 📅 Sent: 2020-06-16 08:01
- 📧 Message 55 of 62
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
---
Previous in thread (54 of 62): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (56 of 62): 🗣️ defdefred (defdefred (a) protonmail.com)