> Clearly, benefits, but I do wonder what can of worms this opens with > regards to confidentiality. "Wait, someone else uploaded this?" >
I agree you need to be careful to leak information here, and e.g. only do this if it was the same user that uploaded it. Maybe there are other reasons for passing the hash in the <request>. But then again, maybe this use case is too contrived to require it. > There is also talks about being able to update content (which I personally dislike) - but your proposal adds quite a bit of complexity there too. A server with dynamic/content-based filenames and updating indeed don't go well together. IMO, allowing updating in itself brings complexity on the server (need to manage permissions) and the client (you need to decide whether you want to re-download files based on cache expiration etc., chat history can change if inline images are updated, ...), so I also prefer to drop update support, and just provide a protocol for uploading files and getting URLs to them. Another reason I can think of for content-based GET URLs is that clients sometimes upload files with incorrect extensions (PNG as JPG), and that some web viewers and frameworks make decisions based on filename extensions (I think I've seen web-based audio players give problems if the files have the wrong extension). A server may want to correct this. Alternatively, it could give an HTTP error, but then we would need to standardize on that too, and users are often baffled by incorrect extension problems. thanks, Remko
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
