We aren't currently supporting async uploads - we will but not exactly in
the
same way as we do async requests... problem is that an async upload cannot
safely and cross-browserly (!) return a text/xml response.
So, we'll probably have to handle uploads separately - which isn't really a
bad thing
Looking at the Upload component for other reasons...
Looking at the example in the documentation:
Does the upload complete before the formSubmit? I presume not but one should
always ask. And does upload work well with async requests... ala gmails
attach file functioanlity?
-Pat
Well I am presuming that no website is intentionally creating a bogus file.
So I am presuming the bogus content originated from a malicious user. This
allows the violation to be handled at the moment it is occuring rather than
much later.
Probably the best solution would be some hook that that w
Isn't this for the reverse situation though, serving files?
Most browsers should be able to tell you what they think the mime type is
for incoming files thoughI guess that could be exposed in the Upload
interface if it's not already..
On 5/1/07, Patrick Moore <[EMAIL PROTECTED]> wrote:
I a
I am just thinking of the upload component having the ability to notify a
method that the file uploaded looks like an HTML as far as IE is concerned.
It would be a tool against someone abusing a tapestry-based website. Fixing
the file or anything else is far beyond my thinking.
On 5/1/07, Jesse K
I always set the "Content-Disposition: attachment" in my header fields of
services returning file data anyways because of related reasons. I don't
think tapestry can do this for anyone but maybe I'm wrong.
On 5/1/07, Patrick Moore <[EMAIL PROTECTED]> wrote:
Hi there --
Brief blog post summariz
