<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 12/05/2012 16:18, Cameron Kaiser wrote:<br>
<span style="white-space: pre;">>>> And like I said
before - if you do want to do that, probe caps.txt first.<br>
>><br>
>> Caps.txt looks like a way to make gopher client
development a pita. If<br>
>> you want to use newer features you will have to send at
least two re<br>
>> quests, of which one implies parsing an arbitrary file.<br>
><br>
> Well, it's cacheable, at least, but your point is
well-taken. Still, it<br>
> works "already."<br>
></span><br>
Of course, then there's the problem of gopher clients that /don't/<br>
understand caps files parsing them like a normal file. I'm
assuming<br>
that it's served to the client but isn't shown to the user, so if
it's<br>
purely a server thing then we might not have that problem. And if
it's<br>
purely server-side, then wouldn't every caps-supporting client
need to<br>
tell the server that it supports caps? If that's the case, it
could<br>
cause problems for some server/client combination's. For example:<br>
<br>
Alice's gopher server provides a service which requires a caps
file;<br>
Bob's client, which has caps support, connects to Alice's server
but<br>
when Bob attempts to use Alice's service, it outputs an error. Why<br>
does it do that? Because, in Bob's user agent string, it doesn't
tell<br>
the server that it can understand caps, so the server removes the<br>
caps-related data from the service's input, meaning the service
can't<br>
understand its input, causing the error.<br>
<br>
I presume I've got some (or all) things wrong in the above example
if<br>
I'm correct about the client needing to tell the server.<br>
<br>
</body>
</html>