files being uploaded are always represented to a destination site as huge-sized (Win64; 0.5.11)

What's the status on this issue? Why has nobody resolved it? Why do you just leave behind bugs? Are you too lazy to fix them? Are they not worth fixing? Do you not care about the Windows version?

I have posted a pretty bunch of obvious Win64 bugs several months ago, all of them are not resolved.
I think they are just too lazy for caring about Windows (;

This bug is probably in WebKitGTK+ itself, rather than Midori. It would be best if you could try to find out what headers Midori sends to the server and/or submit a bug report on the WebKitGTK+ bug tracker (I couldn't reproduce as I couldn't get Midori to run under WINE) which is linked on <http://webkitgtk.org/>.

I submitted a bug report. https://bugs.webkit.org/show_bug.cgi?id=129216

Great work, comrade ioL ^_^
>Gue5t
I wish I could emulate a server-client interaction between Midori[Win64] and Apache to find out the transmitted file header contents myself, but that would take several days of reading manuals in my lamish case ^_^...

There is always MIDORI_DEBUG=headers midori.exe - it will print to the console header from libsoup (network lib).
You can see if it shows something odd. On win there is/was server2go - which was apache + php + mysql in a one-click/portable form.

Do you have some site that does not need an account and still triggers this bug?

Just now I have tried to upload some mp4 video files to several piracy-friendly anonymous file hostings via Midori 0.5.7 WINx64... DAMN! All of these file hostings do not trigger the bug we discuss here, and the files are uploaded to them as they have to.
Nevertheless, Google-com and Mail-ru mail servers still fail to measure the attachment file size (@M-ru even accepts an attachment file, but still indicates a wrong size for it). Of coarse, this happens both in Midori 0.5.7 and Midori 0.5.5.

Server2Go still exist, but for me it is almost useless - I do not have any skills for using it in this case. All I can do with it is runinng its EXE and watching it starts and immediately shuts down :D

still you can try with soup tracing i guess
set MIDORI_DEBUG=headers
and then run midori (-p private should work too) from cli, maybe you spot something obviously wrong on those mail sites.

Would be nice to try those as well with current version of webkitgtk on windows but it is unfortuately very unstable at the moment (you would need to basically disable js to test anything) so not sure if it would be that helpful here

Well, at least I tried to make soup tracing.

I attach here a *.zip with cmd console & Midori screen shots - made right during some of those hundreds milliseconds when the engines seemed to output in the log most intensively.

I must notice that command line console in "headers" debug mode flows pretty fast when Midori browses through the Web 2.0 - and I see no evident way to process the entire sheet, just because it does not fit into the console window. I can only say that I have not visually noticed any sign of critical malfunction there.
Nevertheless, there are some ЕГГОГs indicated in the very beginning of Midori's start-up process - they are clearly visible on the first shot.

The bug is in Midori 0.5.8 on Windows 2008 R2 (x64).
You may use http://www.virustotal.com/ for checking it -- no login needed.

Use Virustotal to check what?
Sorry, I don't quite get your comment Kestutis Snieska.

Comrade inandoutland is probably too lazy to read the entire discussion here and then check out www.virustotal.com.
I perfectly got the comment of Kestutis. It is about uploading files to VirusTotal to check out the file length reported to VirusTotal improperly by Midori.

Sorry for not clear comment (You can get it more clear in the duplicate bug #1298406 ). Reporter got it right.
I've just tested 0.5.8 on Windows XP x64 Pro -- the same problem here.

Command line midori.exe --portable
Midori 0.5.8 ((null)) Midori.exe
GTK+ 3.6.4 (3.6.4) Glib 2.34.3 (2.34.3)
WebKitGTK+ 1.10.2 (1.10.2) libSoup 2.40.3
cairo 1.12.10 (1.12.10) libnotify No
gcr No granite No
Platform Windows NT 5.2
Identification Mozilla/5.0 (Windows NT 5.2) AppleWebKit/537.6 (KHTML, like Gecko) Chrome/18.0.1025.133 Safari/537.6 Midori/0.5
Video Formats H264 [x] Ogg Theora [x] WebM [x]

Netscape Plugins:

Pando Web Plugin Pando Web Plugin
INNORIX Multi Platform Solution INNORIX Multi Platform Solution
Google Update Google Update
Picasa Picasa plugin
VLC Web Plugin VLC media player Web Plugin 2.1.3
Torrent Stream P2P Multimedia Plug-in 2 Torrent Stream Plug-in Version 2.0.9.0, Copyright (c) 2012 Innovative Digital Technologies
Adobe Acrobat Adobe PDF Plug-In For Firefox and Netscape 10.1.9
Shockwave Flash Shockwave Flash 12.0 r0
Java Deployment Toolkit 6.0.240.7 NPRuntime Script Plug-in Library for Java(TM) Deploy
Silverlight Plug-In 5.1.30214.0

Oooo, you're using XP....
Yes, I have read all the comments and still do not get it.
(PS: Put update here)

NOW I get it(read the duplicate).

Hello there
The bug still exists in version 5.11 on the same machine. Here is a new shot.

\The cmdln path options for usual config file override was made earlier this year to bypass a bug with startup, which is already fixed. I still do not remove the bypass path because I do not want to mess with making that file a default config. I would better install Midori 0.6 with a completely new default factory configuration :)\

My about:version is now {
Command line F:\Program Files 2 (x86)\Midori\bin\midori.exe --config=F:\mcfg
Midori 0.5.11 ((null)) Midori.exe
GTK+ 3.14.12 (3.14.12) Glib 2.42.2 (2.42.2)
WebKitGTK+ 2.4.9 (2.4.9) libSoup 2.48.1
cairo 1.12.16 (1.12.16) libnotify No
gcr No granite No
Platform Windows NT 6.1
Identification Mozilla/5.0 (Windows NT 6.1) AppleWebKit/538.15 (KHTML, like Gecko) Chrome/18.0.1025.133 Safari/538.15 Midori/0.5
Video Formats H264 [x] Ogg Theora [x] WebM [x]

Netscape Plugins:

Google Update Google Update
Windows Activation Technologies Windows Activation Technologies Plugin for Mozilla
Shockwave Flash Shockwave Flash 19.0 r0
Unity Player Unity Player 4.3.5f1
Html5 location provider AlterGeo browser helper object
Silverlight Plug-In 5.1.40728.0
}