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 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! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20061031/3bc31fb0/attachment.pgp>
