Android Browser problems: selection download, upload, authentication

[SamePaul]

1st of all I hope everything is OK with the author. Seems he just got tired of HFS and this forum a bit
Now, good news I have almost ready template that CSS-optimized for both desktop browser and mobile. Yes, not 2 templates - just one

But I have some problems on my HTC Desire browser.
1. Browser cannot login via "login" link. Namely when I click link https://my-site.com/~login browser asks me for username and password, but then returns to root folder ... and we're not logged in! Problem is that browser consider "~login" part as folder and thus it thinks that authentication valid only for /~login/ tree. If for example I try to enter password-protected folder https://my-site.com/secure/ I'm asked for password and stay authenticated for this folder and all subfolders as well.
I proposed once to support in HFS alternative authentication URL like https://my-site.com/?mode=auth or even better - support template macro {.setHttpError|code.}. I prefer 2nd solution, as it allows more flexible authentication schemes based on cookies etc.

2. Browser can't download archived content. It means, that if I select multiple files in list and then click "Archive" button, nothing happens. Regular file downloading by clicking link works without any problem.
I analyzed response headers of HFS for different scenarios like archiving files, downloading standalone .tar file. In general difference is in content-type and content-disposition: application/x-tar for archiving and application/octet-stream + "attachment" for downloading. Maybe Android doesn't know how to handle /x-tar or can't live without "attachment" keyword? Maybe it's worth to use 2nd variant for both transfers?
There is also chance that Android can't handle correctly downloading after POST... don't know how to verify this.

3. Uploading isn't working at all. I saw in other post that request header may help in debugging, so here they are

Code: [Select]

> POST /upload/sandbox/ HTTP/1.1
> Host: 192.168.2.100
> Accept-Encoding: gzip
> Accept-Language: en-US
> Cookie: HFS_SID=0.939639982767403
> Accept-Charset: utf-8, iso-8859-1, utf-16, *;q=0.7
> Referer: https://192.168.2.100/upload/sandbox/
> User-Agent: Mozilla/5.0 (Linux; U; Android 2.3.4; en-us; HTC Desire Build/MIUIAndroid 1.5.13) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
> Origin: https://192.182.2.100
> Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> Authorization: Basic ****************
> Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryKFSXwgyWckAMgljQ
> Content-Length: 554727Thought it may be use of SSL or authentication, but without it result was the same.

Code: [Select]

> POST /upload/sandbox/ HTTP/1.1
> Host: 192.168.2.100
> Accept-Encoding: gzip
> Accept-Language: en-US
> Cookie: HFS_SID=0.939639982767403
> Accept-Charset: utf-8, iso-8859-1, utf-16, *;q=0.7
> Referer: http://192.168.2.100/upload/sandbox/
> User-Agent: Mozilla/5.0 (Linux; U; Android 2.3.4; en-us; HTC Desire Build/MIUIAndroid 1.5.13) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
> Origin: http://192.168.2.100
> Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryLtRTXXJs6CB4l4hy
> Cache-Control: no-cache
> Pragma: no-cache
> Content-Length: 554727Comparing to upload from desktop browser

Code: [Select]

> POST /upload/sandbox/ HTTP/1.1
> Host: localhost
> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip, deflate
> Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 115
> Connection: keep-alive
> Referer: http://localhost/upload/sandbox/
> Cookie: HFS_SID=0.665004789130762
> Content-Type: multipart/form-data; boundary=---------------------------248749113712
> Content-Length: 108673The only significant difference I see is "boundary" part, however I'm not very familiar with encoding, but maybe this "WebKitFormBoundary" makes HFS to choke?

UPD: Forgot to mention, HFS Version 2.3 beta 279

[rejetto]

0. it's true that i'm somewhat tired with this project, because of the underneath technology (9 years have passed), but this is not the real cause of my limited activity. Last week I've been working like 14 hours a day, from monday to sunday. Things like these can be a hard limit to overcome.

1. cookie authentication is on the way. Sadly i had to stop few months ago because of the lack of time. It's harder than you may think since i'm making it backward compatible, so that current templates will continue to work. It's already quite working but i have to solve some problems. Sharing it with you may be a good idea to speed up the process.

2. i applied your suggestion for the next release.

3. it's likely that the problem isn't in the header part. I have an android device and will test it, but that may vary with the browser.

[SamePaul]

0. Completely understand and support. Deadline has us all from time to time
1. Cookie authentication was just an example. What I actually proposed - macro that can modify HTTP response code. Template then may do all the rest work. Of course I'd be glad to help you in whatever I can.

[rejetto]

yes, something like that was already in the to-do list obscurely written

+ macros missing to cache a folder: {.reply|content=|var=|code=|filename=|mime=.}