|
On 12/05/2012 16:18, Cameron Kaiser wrote: >>> And like I said before - if you do want to do that, probe caps.txt first. >> >> Caps.txt looks like a way to make gopher client development a pita. If >> you want to use newer features you will have to send at least two re >> quests, of which one implies parsing an arbitrary file. > > Well, it's cacheable, at least, but your point is well-taken. Still, it > works "already." > Of course, then there's the problem of gopher clients that /don't/ understand caps files parsing them like a normal file. I'm assuming that it's served to the client but isn't shown to the user, so if it's purely a server thing then we might not have that problem. And if it's purely server-side, then wouldn't every caps-supporting client need to tell the server that it supports caps? If that's the case, it could cause problems for some server/client combination's. For example: Alice's gopher server provides a service which requires a caps file; Bob's client, which has caps support, connects to Alice's server but when Bob attempts to use Alice's service, it outputs an error. Why does it do that? Because, in Bob's user agent string, it doesn't tell the server that it can understand caps, so the server removes the caps-related data from the service's input, meaning the service can't understand its input, causing the error. I presume I've got some (or all) things wrong in the above example if I'm correct about the client needing to tell the server. |
_______________________________________________ Gopher-Project mailing list Gopher-Project@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project