Hi, On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote:
I just stuck it on a label button for now.
It looks quite informative.
Already an improvement over Firefox, where I only find out that I mistyped the filename when the server doesn't get the file.
Somewhere that accepts files: http://validator.w3.org
Edge case that I just noticed: If I read in a file, delete that file, and try to read it in again (uses E2EReload), the submit will send the (now empty) file because a_Capi_get_buf() finds the (now empty) entry in cache. So I'll have to find out where an a_Cache_entry_remove_by_url() should go.
Yes. Please also add a file size threshold, to avoid a dillo exit from an out of memory condition. Committed! -- Cheers Jorge.-
On Fri, Apr 11, 2008 at 02:33:50PM +0000, corvid wrote:
Jorge wrote:
Please also add a file size threshold, to avoid a dillo exit from an out of memory condition.
Does something like this sound about right?
Yes, but I'd add a WEB_RootUrl check: + if (entry->Flags & CA_HugeFile) { + AbortEntry = TRUE; + a_UIcmd_set_msg(Client_bw,"Huge file! (%dMB)", + entry->ExpectedSize / (1024*1024)); ++ if (ClientWeb->flags & WEB_RootUrl && + dStrcasecmp(URL_SCHEME(entry->Url), "file")) + OfferDownload = TRUE; + }
diff -pur dillo2/src/cache.c dillo2-cur/src/cache.c --- dillo2/src/cache.c 2008-03-29 15:14:11.000000000 +0000 +++ dillo2-cur/src/cache.c 2008-04-11 14:25:55.000000000 +0000 @@ -861,16 +861,18 @@ static void Cache_process_queue(CacheEnt } else { Client_bw->redirect_level = 0; } - if (entry->Flags & CA_HugeFile) { - a_UIcmd_set_msg(Client_bw,"Huge file! (%dMB)", - entry->ExpectedSize / (1024*1024)); - AbortEntry = OfferDownload = TRUE; - } } else { /* For non root URLs, ignore redirections and 404 answers */ if (entry->Flags & CA_Redirect || entry->Flags & CA_NotFound) Client->Callback = Cache_null_client; } + if (entry->Flags & CA_HugeFile) { + AbortEntry = TRUE; + a_UIcmd_set_msg(Client_bw,"Huge file! (%dMB)", + entry->ExpectedSize / (1024*1024)); + if (dStrcasecmp(URL_SCHEME(entry->Url), "file")) + OfferDownload = TRUE; + }
/* Set the client function */ if (!Client->Callback) {
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
-- Cheers Jorge.-
Jorge wrote:
On Fri, Apr 11, 2008 at 02:33:50PM +0000, corvid wrote:
Jorge wrote:
Please also add a file size threshold, to avoid a dillo exit from an out of memory condition.
Does something like this sound about right?
Yes, but I'd add a WEB_RootUrl check:
+ if (entry->Flags & CA_HugeFile) { + AbortEntry = TRUE; + a_UIcmd_set_msg(Client_bw,"Huge file! (%dMB)", + entry->ExpectedSize / (1024*1024)); ++ if (ClientWeb->flags & WEB_RootUrl && + dStrcasecmp(URL_SCHEME(entry->Url), "file")) + OfferDownload = TRUE; + }
I saw that the current code only did so for root URLs, but I didn't realize it was intentional. BTW, do you think dillo should do anything if it gets a huge file from a server but didn't know to expect the file to be huge ahead of time (no content length, or chunked transfer encoding)?
On Fri, Apr 11, 2008 at 05:48:25PM +0000, corvid wrote:
Jorge wrote:
On Fri, Apr 11, 2008 at 02:33:50PM +0000, corvid wrote:
Jorge wrote:
Please also add a file size threshold, to avoid a dillo exit from an out of memory condition.
Does something like this sound about right?
Yes, but I'd add a WEB_RootUrl check:
+ if (entry->Flags & CA_HugeFile) { + AbortEntry = TRUE; + a_UIcmd_set_msg(Client_bw,"Huge file! (%dMB)", + entry->ExpectedSize / (1024*1024)); ++ if (ClientWeb->flags & WEB_RootUrl && + dStrcasecmp(URL_SCHEME(entry->Url), "file")) + OfferDownload = TRUE; + }
I saw that the current code only did so for root URLs, but I didn't realize it was intentional.
It may look a bit strange, but a download offer on a URL the user didn't request directly may be puzzling.
BTW, do you think dillo should do anything if it gets a huge file from a server but didn't know to expect the file to be huge ahead of time (no content length, or chunked transfer encoding)?
Yes, of course. -- Cheers Jorge.-
Jorge wrote:
On Fri, Apr 11, 2008 at 05:48:25PM +0000, corvid wrote:
BTW, do you think dillo should do anything if it gets a huge file from a server but didn't know to expect the file to be huge ahead of time (no content length, or chunked transfer encoding)?
Yes, of course.
I mean should it take some particular action (a dialog or something) once it figures out that it's N megs into something big?
On Fri, Apr 11, 2008 at 07:12:06PM +0000, corvid wrote:
Jorge wrote:
On Fri, Apr 11, 2008 at 05:48:25PM +0000, corvid wrote:
BTW, do you think dillo should do anything if it gets a huge file from a server but didn't know to expect the file to be huge ahead of time (no content length, or chunked transfer encoding)?
Yes, of course.
I mean should it take some particular action (a dialog or something) once it figures out that it's N megs into something big?
Good question. ;) Considering that we can only flag the entry as HUGE after it has grown a lot, aborting the connection and removing the entry is not an option. For root URLs: stopping the transfer could be offered, but OTOH the user can press the "Stop" button at will, and if he hasn't, we can assume he wants to continue (i.e. leave dillo2 "as is"). For non root URLs (mainly images): stopping the transfer once the threshold has being met, could be. Especially if we consider that the pixmap size is much bigger than the data, it makes sense. If it's simple to implement, it may be worth the effort. BTW, if we have a user clicking an iso, or movie that's served as "text/plain", the internal content-type checker will catch it, abort the connection, and leave the option of "Save link as...". -- Cheers Jorge.-
Jorge wrote:
On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote:
If I read in a file, delete that file, and try to read it in again (uses E2EReload), the submit will send the (now empty) file because a_Capi_get_buf() finds the (now empty) entry in cache. So I'll have to find out where an a_Cache_entry_remove_by_url() should go.
Yes.
It looks like I'd have to figure out CCC for this, which would likely be more trouble than it's worth.
On Fri, Apr 11, 2008 at 09:21:16PM +0000, corvid wrote:
Jorge wrote:
On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote:
If I read in a file, delete that file, and try to read it in again (uses E2EReload), the submit will send the (now empty) file because a_Capi_get_buf() finds the (now empty) entry in cache. So I'll have to find out where an a_Cache_entry_remove_by_url() should go.
Yes.
It looks like I'd have to figure out CCC for this, which would likely be more trouble than it's worth.
OK, I'll allocate some time to give it a look. -- Cheers Jorge.-
Jorge wrote:
On Fri, Apr 11, 2008 at 09:21:16PM +0000, corvid wrote:
Jorge wrote:
On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote:
If I read in a file, delete that file, and try to read it in again (uses E2EReload), the submit will send the (now empty) file because a_Capi_get_buf() finds the (now empty) entry in cache. So I'll have to find out where an a_Cache_entry_remove_by_url() should go.
Yes.
It looks like I'd have to figure out CCC for this, which would likely be more trouble than it's worth.
OK, I'll allocate some time to give it a look.
Cool. Sort of on topic, what do you think of reviving use of the bug tracker for the various little things that are easy to forget about?
On Sat, Apr 12, 2008 at 02:06:42AM +0000, corvid wrote:
Jorge wrote:
On Fri, Apr 11, 2008 at 09:21:16PM +0000, corvid wrote:
Jorge wrote:
On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote:
If I read in a file, delete that file, and try to read it in again (uses E2EReload), the submit will send the (now empty) file because a_Capi_get_buf() finds the (now empty) entry in cache. So I'll have to find out where an a_Cache_entry_remove_by_url() should go.
Yes.
It looks like I'd have to figure out CCC for this, which would likely be more trouble than it's worth.
OK, I'll allocate some time to give it a look.
Cool.
Patch committed. After pondering whether to add a URL flag to discriminate a file-input loaded-file (to be able to free it later), the complexities of it being also used/displayed by another Dillo window (and the inherent races), and the necessary handling code, I preferred a local load. The async approach may be done, but the committed approach is simpler, gets the work done, and may be extended to handle multiple files. I also added a handy heuristic for content-type detection of files (it works well with the w3c validator). -- Cheers Jorge.-
participants (2)
-
corvid＠lavabit.com -
jcid＠dillo.org