rejetto forum

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - skb

Pages: 1 2 3 4
This is very probably un-related, as I wasn't using WFetch, but but just a few days ago I had an issue where some uploads from my Android program were failing, and it was because they requested chunked encoding rather than sending a Content-Length.

My log output was like yours: In the failed uploads I saw the POST request without the previous "Uploading" and "Fully Uploaded" lines.

Try "Menu > Log > Log what > Requests dump", so that HFS will print the requests headers it receives. Then see if the failing cases have Transfer-Encoding chunked.

(In my case, looking with Wireshark, I saw that HFS was returning a 405 error response to the chunked mode requests, but the Android file upload routine (in the Phonegap files plugin) was losing this, and returning a 200 response to my code. The fix for me was an optional flag to this Android upload routine telling it not to use chunked mode. Perhaps WFetch has a similar no chunks option.)


Fixed by version 2.3f  :D (Via changes to the standard hfs.tpl file included in this version).

I had the problem recur despite the workaround suggested earlier in this thread, but upgrading to version 2.3f and patching my stripped-down version of the hfs template with the changes to the cookie handling from the new hfs.tpl made the problem go away.

Thanks for the fix, Rejetto!


HTML & templates / Re: Limits to uploaded files by size?
« on: August 09, 2015, 01:12:48 AM »
Ah, LeoNeeson, very clever using Google to search the forum! I'd never thought of that, and was trying to find stuff using only the local search tool. Thanks for the examples!


HTML & templates / Re: Limits to uploaded files by size?
« on: August 09, 2015, 01:07:38 AM »
Wow, thanks! That is quite a nice solution! I was thinking I'd need to code some macros; very great to have it as a new built-in! :)

HTML & templates / Limits to uploaded files by size?
« on: July 26, 2015, 01:11:39 AM »
Is there an easy way to restrict uploads to "small" sizes, e.g. only files less than 100KB?

Can the system know the file size before it is uploading it? Alternatively, is there any way to abort an upload if the file is larger than a limit? Or, perhaps drop it after the upload is complete? Do we know the size when the [upload completed] event happens? Is it possible to delete a large file at that point?

I fear that this question might be answered already, but the terms I tried to search for (like "file size") are so widely used that I did not find useful results.

Thanks for any pointers.

HTML & templates / Re: Format of " (1)" added to duplicate file name?
« on: July 26, 2015, 01:00:34 AM »
Thanks! Very slick! Impressive what you can do with macros.

Sorry, been away for awhile. I came back because I hit this bug again on Firefox but not Chrome (but Firefox is the browser I'd used more in the past for HFS access, so it was more likely to have old context.)

I'll put your suggested fix in my template now, but it will probably be a while before the bug gets triggered again.

When it happened today, I tried deleting the HFS cookie with Firefox's "File > Preferences... > Privacy > Remove individual cookies", and then restarted my browser, and this did not help. Then I deleted the cookie again, restarted the server and restarted my browser, and it still didn't help. I tried Firefox's "clear everything for the past hour", and it didn't help (because I think whatever was causing the problem is from a few weeks ago.)

Finally, I had Firefox clear all of its saved stuff from any time (History > Clear recent History... ; and then put a check by every item, and set "Time range to clear" to "Everything". Then browser restart, and now a rename worked.

I'd been running HFS regularly back when I first posted, but then shipped a version, and shut down my test copy. So, my server has been down for a few weeks, though the actual users have not reported any issues with theirs.

Today I fired up my copy again, and hit the bug when I first logged in. So, whatever bit of history was confusing Firefox is probably several weeks old.

Anyway, sorry to leave this thread hanging so long. I'll install your patch and see if the bug comes up again.

Thanks Rejetto,

In fact, I often restart my development server when updating my template, and only rarely get this error message. So, not directly caused by a server restart. Perhaps a server restart in conjunction with a previous cookie expiring?

Also, once it does occur, it persists through browser restarts, page reloads, etc. That is, if I restart the browser, then when I go back to my server, I have to log in again (as expected), and after login, Renames will still fail with the same error about a bad session.

Not sure if a server restart after the error occurs will clear the situation. I don't think so, but not 100% sure I've tried this explicitly.

Clearing cache in the browser doesn't help, with or without a browser restart; this was explicitly tested.

Clearing cookies in the browser does resolve the issue.

(Again, I don't have reports of it happening in the field, though I warn users of the possibility in my instructions. It may be just a side effect of me running sites with the same template on two different servers, one at localhost on my dev machine, and one online at a global static IP, with the same logins on both, and my browsing back and forth between the two sites. The actual users use their single production site only, not two different ones.)

Locally, I've had it happen sometimes with both Firefox and Chrome, on Win7 and Win8 clients, and with a Win7 and Win8 server. Also, it happens sometimes to the localhost server, and sometimes to the remote server. But, I've not found the pattern that will reproduce it.

I'll keep trying to get a reproducible error, as I don't think we can hope to fix it without that. I'm seeking background on the function of cookies to guide me in finding a reproducible cause.


I see from reading the default template that HFS uses a "session ID" cookie named HFS_SID for its rename and comment actions, but I don't really get how this cookie works or what it accomplishes. This cookie is involved with rename operations because in the "ajax" function, there is:
Code: [Select]
data.token = getCookie('HFS_SID');
but I'm not clear where or how that cookie gets set.

The problem I'm having is that sometimes (but frequently enough to be annoying) the cookie apparently gets messed up, and the rename command fails with "Error: bad session".  I've not yet been able to work out what circumstances cause this situation to occur, but once it does, then it continues until I clear cookies from my browser, and restart the browser.

I think the issue may come up when I switch between two different instances of HFS, e.g. when I work with a copy on localhost during development, and also with a "production" copy on a host out on the net, where I have the same username on both instances. (If this is the only trigger, then I don't have to worry about actual users hitting this cookie problem, but I can't tell.)

It also seems more likely to occur if I have not used the server for several days, but again, I can't tell if this is actually a trigger, or just coincidence. (Perhaps my session cookie "expires" if I don't log in for a few days, and then I get this when I next log in?)

Or, is there an issue if the server is restarted between my logins?

I'd like to understand the situation enough to know what circumstances actually cause it, so I can know if it might actually crop up for real users. So far, I have not been able to find that pattern that reproduces the "bad session" error on rename or comment.

Can anyone explain how cookies are supposed to work, and how they interact with the rename process, and what the HFS_SID cookie is about?

It gets tested (I think) with the following macro:
Code: [Select]
check session=break|if={.{.cookie|HFS_SID.} != {.postvar|token.}.}|result=bad session

but again, I don't really know what that does, or when, or why.

Thanks for any clues!

HTML & templates / Re: Format of " (1)" added to duplicate file name?
« on: March 26, 2015, 05:04:06 AM »
Yes, thank you.

However, HFS already does an almost perfect job of checking for possible duplicate names and renaming them intelligently. I don't want to re-invent all this in macros! I'd just prefer to not have the space in the resulting name.

But, not a high priority!


HTML & templates / Re: Format of " (1)" added to duplicate file name?
« on: March 09, 2015, 02:14:57 AM »
Thanks for the reply.

At the time [Upload Name] is called, HFS has possibly not yet checked to see if the name will clash, and does not seem to indicate the proposed alternative name it will use.

That is, even if "filename" already exists in the current folder, so that HFS will indeed actually save the newly uploaded file as "filename (1)"; still, the %item-name% shown is merely "filename", not "filename (1)", within the [Upload Name] handler.

Is there an alternative %item-something% that gives the proposed name HFS will really use when it writes out this file?

If the "non-clashing" name is not available from HFS, then, for me to handle it means I'll need to replicate all of the logic that HFS already has in place to come up with a non-overlapping name. This seems both redundant and tricky.

I'd rather there was a way to suggest what separator character HFS should use before its added "(number)" suffix. Currently this separator is " ", and I'd prefer, say, "_" . With the change of separator character, then the existing file name code would fit my needs.

But, I guess this is not that big a deal. So, for now, I'll probably just ignore the issue, rather than implementing my own "check for duplicate file names" logic.


HTML & templates / Format of " (1)" added to duplicate file name?
« on: March 06, 2015, 04:39:10 AM »
Is it possible to change the format of the numbers added to an uploaded file name when the menu item "Upload > Number files on upload instead of overwriting" is selected?

Currently, HFS adds " (uniqueNumber)" at the end of the name, and the embedded space is a pain for some command line file processing.

Is there any way to change the format to just "(uniqueNumber)" without the dang space?

In the [upload name] event, %item-name% has the file's original, possibly duplicate name, without the added string, " (1)", say. Is there a different %tag% that has what will be the file's name after HFS makes it unique?

Alternatively, I suppose I could use [upload completed], and search for names with " (" in them, and then rename them to remove the space, but that seems worse than fixing the name before the file is saved.


As far as I know (from limited testing I did when I was wondering about using item-added), these timestamps are not preserved across server restarts.

However, as far as I can see, when items are uploaded, the new file that is created on the server gets the current date and time. Thus, the modification time saved by the OS (as shown via  %item-modified%) is generally the time the file was added.

(Perhaps an exception is if you are manually moving files from elsewhere into the real folders on your server, rather than uploading them via HFS. In this case, perhaps you could add something like the command line "touch" utility to update the modification times of the files you add to the current time as you add them.)


FIXED in HFS version 2.3e  :)

HTML & templates / Re: %comment% in ~files.lst ?
« on: February 23, 2015, 01:00:45 AM »
Ah, thanks! (I didn't really get the section [comment] reference; was just thinking of the more obvious item comments).


Pages: 1 2 3 4