On 10/31/06, toad <toad at amphibian.dyndns.org> wrote: > On Tue, Oct 31, 2006 at 09:34:23PM +0100, bbackde at googlemail.com wrote: > > Why do you add this level of complication? Why could'nt a key with > > filename just be recognizable, e.g. if you change the tralining part > > "AAEC--8" into something different? > > If it breaks compatability now this is no problem because its breaken > > already... > > At the moment, a key with a superfluous filename will be requested > successfully. > > The problem is that at the moment freenet URIs don't behave like normal > URIs. You can add an arbitrary number of extra path elements (slash > followed by string not including slash), and it still work. Which means > we can't compare them. > > > > Some way to add an indication to the keys text representation would be > > very helpful. > > Perhaps. What would you suggest? > > CHK at blah,blah,blah,filename.ext > CHK at blah,blah,blah?filename=filename.ext
I vote for a clear solution that indicates the different key types (with/without filename) in the chk key itself, instead of adding another incompatible new extension. As I said the (currently) fix extension AAEC--8 seems to be a good choice for me, why not simply make it AAEC--9 or whatever for keys WITH filenames? This allows applications to clearly differentiate the different key types and how to handle them. > > The ? parameters are not part of the URI, they're specified by fproxy, but > they can be standardised and supported by fproxy and frost if it's helpful > to do so; we can already e.g. override the mime type through ? parameters). > > Any other options? > > > > On 10/31/06, toad <toad at amphibian.dyndns.org> wrote: > > >On Tue, Oct 31, 2006 at 07:50:06PM +0100, bbackde at googlemail.com wrote: > > >> Situation: > > >> > > >> A key uploaded with filename must be downloaded using the same filename. > > >> A key uploaded without filename must be downloaded without a filename (?) > > >> > > >> But the people post keys in format CHK at abc/xyz , and they don't know > > >> if the file was uploaded with or without a filename. > > >> > > >> How should an application behave if the user enter a key with > > >> CHK at abc/xyz in the download box??? How can the application determine > > >> if it should request the key WITH or WITHOUT the filename? > > > > > >It should request the key exactly as the user provided it. > > > > > >In the near future, this will continue to work with keys uploaded > > >without filename which have then had a filename appended to them. In the > > >long run, it will yield a specific error code indicating too many path > > >elements. If the client is trying to be excessively helpful and > > >back-compatible it may delete the last path element and try again after > > >receiving such an error message. Just as if fproxy gets an error > > >indicating too few path elements, it appends a "/", and sends a > > >permanent redirect to the new key (the advantage being that bookmarking > > >then keeps the new key rather than the old one). > > >> > > >> Currently Frost completely fails downloading keys WITH filename, > > >> because it removes the filename from the key. > > >> > > >> Help, please! > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (GNU/Linux) > > iD8DBQFFR7kZA9rUluQ9pFARAnEuAKCqMzf57A0OxTztVJ/KgFzjix+xuACfRC12 > wC7GO0h24++au1YkTwgDSpc= > =BMMo > -----END PGP SIGNATURE----- > > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > >