John Cowan <cowan at ccil.org> writes: > A Dioscuri request starts out with the client sending a single line, > <URL><SP><MEDIA-TYPE><CR><LF>. This indicates that a body follows which > should be interpreted according to the media type. For example, "gemini:// > example.org/foo text/gemini\r\n" means that the Dioscuri server should do > something with the following body, which is of type text/gemini. Exactly > what happens depends on the server and the URL. For example, it might > replace the contents of "foo" with the uploaded body. Alternatively, > "gemini://example.org/do/this text/javascript\r\n" might cause the > JavaScript in the uploaded body to be executed on the server. Does Dioscuri have the same line-length limits as Gemini? > > By mutual agreement between the client and the server, the server may > return "70 <URL>\r\n" not followed by a body. This code means that the > request has succeeded, but rather than the server sending a response body > in the same TCP connection, the response body can be found at <URL>. > > A use case for this is that the client wishes to add a new file to a > container (directory or whatever) in the server but leaves it up to the > server to choose the new URL according to some algorithm (random, > timestamp, etc.) So a request of "<container-URL> text/gemini\r\n" > followed by the body would in such a case respond "60 <object-URL>\r\n", > meaning that the new resource can be found at <object-URL>. > Do you mean "70" here instead of "60"? > > Finally, an implementation note: the TCP library used to implement Dioscuri > clients must be able to separately close the input and the output sides of > the TCP connection to the server. So in the application server discussed > above, the client closes the output side of its socket when it has sent the > body, and the server receives EOF when it attempts to read more body. > However, the input side on the client must remain open so that the > server's response can be read. Are there any limits on payload length from the client? Are there any plans for the client to indicate to the server the length of the payload? What happens if the server encounters a fault while reading in the entire client payload? Is there any guidance on timeouts? Should implementors assume that timeouts are quick and the server should hangup quickly if nothing is found on the client's send stream, or is this application dependent so that it's up to the server/endpoint to determine timeouts (e.g. for a streaming application)? My worry is that opening connections to the server and keeping the server send connection open can quickly exhaust the number of sockets/fds the server has available. - meff
---
Previous in thread (1 of 16): 🗣️ John Cowan (cowan (a) ccil.org)
Next in thread (3 of 16): 🗣️ Sandra Snan (sandra.snan (a) idiomdrottning.org)