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

Bug #1234542 reported by Oleg Dozorov on 2013-10-03
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Midori Web Browser
Confirmed
Medium
Unassigned

Bug Description

When I try to upload some tiny files to a post-office site, the post-office interface says that these files are NNNN GigaBytes long. So, most of such systems do not accept my files at all, some of them try to upload files to a file hosting. Technically, the upload process itself may work OK in some cases (at least, once I was lucky to upload 50 MBytes video to VK.com - because VK runs a very robust user interface, which usually works in all possible cases; nevertheless, even VK later failed to measure a size of that Midori-uploaded content)... But, as I alredy said, the uploading file size is reported totally wrong by Midori.

(I use: Midori 0.5.5 (En-UK), win7 (Ru, genuine); Intel x64 triple-core 3 GHz; 4 Gbyte RAM; ATI video.

Here is what Midori says about my desktop computer system in its about:version...
{
Version numbers in brackets show the version used at runtime.

Command line F:\Program Files 2 (x86)\Midori\bin\midori.exe
Midori 0.5.5 ((null))
GTK+ 3.6.2 (3.6.2) Glib 2.34.3 (2.34.3)
WebKitGTK+ 1.10.1 (1.10.1) libSoup 2.40.2
cairo 1.10.2 (1.10.2) libnotify No
gcr No granite No
single instance Sockets
Platform Windows NT 6.1
Identification Mozilla/5.0 (Windows NT 6.1) 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:

Google Update Google Update
Java Deployment Toolkit 7.0.400.43 NPRuntime Script Plug-in Library for Java(TM) Deploy
Windows Activation Technologies Windows Activation Technologies Plugin for Mozilla
Shockwave Flash Shockwave Flash 11.8 r800
Java(TM) Platform SE 7 U40 Next Generation Java Plug-in 10.40.2 for Mozilla browsers
Unity Player Unity Player 3.5.5f3
Silverlight Plug-In 5.1.20513.0
}
)

InAndOutLand (inandoutland) wrote :

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?

Oleg Dozorov (fernitoid) wrote :

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 (;

gue5t gue5t (gue5t) wrote :

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/>.

Oleg Dozorov (fernitoid) wrote :

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 ^_^...

Paweł Forysiuk (tuxator) wrote :

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?

Oleg Dozorov (fernitoid) wrote :

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

Paweł Forysiuk (tuxator) wrote :

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

Oleg Dozorov (fernitoid) wrote :

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.

Changed in midori:
status: New → Confirmed
importance: Undecided → Medium

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.

InAndOutLand (inandoutland) wrote :

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

Oleg Dozorov (fernitoid) wrote :

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

InAndOutLand (inandoutland) wrote :

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

InAndOutLand (inandoutland) wrote :

NOW I get it(read the duplicate).

Oleg Dozorov (fernitoid) on 2015-11-01
summary: files being uploaded are always represented to a destination site as
- huge-sized (Win64; 0.5.5)
+ huge-sized (Win64; 0.5.11)
Oleg Dozorov (fernitoid) wrote :

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
}

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.