Consistent upload failures.

[thecdnhermit]

I was using Hupl with your single file php uploader with consistent positive results until recently.

I hve now been getting failed uploads, with simply the html of your single file upload page being returned. I updated to the recent version, but the issue has persisted. Samsung Galaxy S22+ with Android 14, fully updated to July 1.

For reference, I also use Weechat-Android, and their uploader still works. Main reason I use Hupl is because I have two file servers, and Hupl had allowed me to upload to the server of my choice.

Upload URL is set to: https://my.domain.com/fileshare/ ( fileshare/ is where your single file php file uploader is located, and this works with Weechat-Android and used to work with Hupl)

File parameter is: file (this also works with Weechat-Android and used to work with Hupl)

Response regex: https://.* (again, this works with Weechat-Android and used to work with Hupl)

If there is anything more I can provide, please let me know.

[Rouji]

Is the same thing happening with x0.at? Might be a webserver config problem or something.

And when has that started happening? Both this and the file host repos don't change much, so maybe it's easily relatable to a recent change.

[thecdnhermit]

Just tried uploading to x0.at, seemed to work fine: https://x0.at/64py.jpg

Same settings as I'm using for both my uploaders.

A couple things that changed around the same general time that this started happening was I upgraded my server and there were android upgrades. I am quite sure that after I upgraded my server I had this working. (Debian 12.)

If interested, you can find me at https://www.thecdnhermit.com/irc/

Otherwise I'll keep up with emails to keep up here.

[Rouji]

I know of some annoying crashy problems with android 14 but none that break the actual upload.

I'm gonna need some way of reproducing your issue. Can you share the URL of your server and/or your webserver (and related) config?

[thecdnhermit]

My fileshare is at https://www.thecdnhermit.com/fileshare/

I use the Apache httpd webserver on Debian Bookworm. I have the following two blocks in my apache2.conf (/etc/apache2/apache2.conf):

<Directory "/var/www/thecdnhermit/fileshare/">
    Options +FollowSymLinks -MultiViews -Indexes
    AddDefaultCharset UTF-8
    AllowOverride None
    RewriteEngine On
    RewriteCond "%{ENV:REDIRECT_STATUS}" "^$"
    RewriteRule "^/?$" "index.php" [L,END]
    RewriteRule "^(.+)$" "files/$1" [L,END]
</Directory>

<Directory "/var/www/thecdnhermit/fileshare/files">
    Options -ExecCGI
    php_flag engine off
    SetHandler None
    AddType text/plain .php .php5 .html .htm .cpp .c .h .sh
</Directory>

I do also have the following block in the same file for the folder one up:

<Directory /var/www/thecdnhermit>
        <IfModule mod_rewrite.c>
          RewriteEngine on
          RewriteCond %{THE_REQUEST} /([^.]+)\.php [NC]
          RewriteRule (.*) /%1 [R=302,L]
          RewriteCond %{REQUEST_FILENAME}.php -f
          RewriteRule ^(.*)$ $1.php [L]
          RewriteCond %{THE_REQUEST} /([^.]+)\.html [NC]
          RewriteRule (.*) /%1 [R=302,L]
          RewriteCond %{REQUEST_FILENAME}.html -f
          RewriteRule ^(.*)$ $1.php [L]
        </IfModule>
</Directory>

However, my second instance of single-php-filehost does not have the last block for it, and Hupl fails the same way.

Both instances work through Weechat-Android or through the web-page itself.

The only difference between the two instances is that my other one doesn't have that last code block above.

Screenshot of my Hupl settings: https://www.thecdnhermit.com/fileshare/iqGu17f8PvXxmfGl.jpg

Screenshot of the error message: https://www.thecdnhermit.com/fileshare/2NjE5_5f6uQLTNob.jpg

Am I missing anything?

[Rouji]

Hm, yeah something's weird. I'll have a proper look at it as soon as I can (probably ~weekend)

[Rouji]

@thecdnhermit Heyo, just letting you know I haven't forgotten about this. I still have no idea what could be going wrong there. Seems to be working now though; did you figure out what it was(?)

[thecdnhermit]

I assume that you mean that when you set Hupl to upload to my (instance of your) service, it works? What are you doing different, then?

I tried again with the same settings as I showed above. That returned the same error as before, shown as the top error in the following image. I cleared the "Response regex" box, and it returned the second response, which says complete, but doesn't seem to have a link to access the upload.

https://www.thecdnhermit.com/fileshare/NERUPfKJYg56me4W.jpg

Uploads still work direct from the webpage or through Weechat-Android.

[Rouji]

I just used the .hupl from the index and it seemed to work fine.

Honestly I have no idea what to even poke at... My guess would've been webserver misconfiguration; trailing backslash problems or something. But that wouldn't cause intermittent issues

[Rouji]

No, sry I misremembered. Didn't use the .hupl. The .hupl link in your index doesn't work right, which might point at the same problem?

[thecdnhermit]

OK so I finally got back to this...found some ambition and got back to attempting to fix stuff.

The .hupl link issue was (from what I can tell) because I was using an older version of the uploader. I updated to the latest copy and now that works.

Hupl works for both of my instances of your uploader, as long as I leave the Response Regex blank, and enable the "Disable Chunked Transfer" box.

If I put https://.* in the Response Regex, it now actually uploads but returns this error along with the link to the file: https://www.thecdnhermit.com/fileshare/icjZUmOdaMvB_LPX.jpg

So it's working, but is this how it's supposed to work?

[Rouji]

if you specify a regex, it uses the first capturing group https://github.com/Rouji/Hupl/blob/b985473921753e3d1cc1bf2840ed333fa210bc31/app/src/main/java/eu/imouto/hupl/upload/HttpUploader.java#L187 So a regex of (.*) would give you the entire output (equivalent to not specifying a regex at all). You had no group in there at all -> error

As for the intermittent weirdness, I have no idea. I can only only guess your web server is configured weirdly or something.