click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Schmidt (JIRA)" <>
Subject [jira] Commented: (CLK-389) FileDownload Control.
Date Wed, 15 Apr 2009 11:14:14 GMT


Joseph Schmidt commented on CLK-389:

> The problem with using a control in a page to render the file download, is that browsers
may ignore the content type
> set in the header, and just look at the file request file extension (*.htm).
This is why I asked (in the issues with other type of content - pdf, json,csv) for a ("link")
Control, not a page. A link could point to a (virtual) URL with any extension (in this case
to the correct file type that will be downloaded.

This issue is also about a "control", not a "page". The idea is to have it in Click so that
this important part of any commercial application to be covered easily.

> I think it is clearer to have it handled by a Servlet
This might be true for public static downloads (a list of static files for download), but
in many commercial applications, this servlet would need to duplicate allot of the code in
pages (or click context): 
- authentication, resource protection, counting, monitoring
- dynamic content generation and interaction with resources the user gave in previous pages,
All these require logic present in other click pages (in a click application), so it would
make very much sense to have it in Click.
A separated download servlet like this (popular one):
would be quite cumbersome to integrate with Click.


> FileDownload Control.
> ---------------------
>                 Key: CLK-389
>                 URL:
>             Project: Click
>          Issue Type: New Feature
>    Affects Versions: 1.5 M1
>            Reporter: Gustav Weber
>            Assignee: Malcolm Edgar
> Add a FileDownload Control.
> (Click has a FileUpload, but no Download control :( ).
> It could be based on this post (but it should be simpler to use):
> Also it should have more features (similar or partially symmetric to FileDownload):
> - support for resume connection (very important for bigger files, to allow users to resume
in case of connection problems - this saves allot of traffic)
> - limit the size of the file to download (practical for dynamic content)
> - support for several file types.
> Advanced feature:
> - limit the bandwith per download connection - this would be very important to prevent
blocking the server if the client has a very high bandwith.
> - limit the download duration - to prevent clients to hang the connection forever.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message