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
>
>

Reply via email to