#2038 - A new twist...

grooveman

Joined: 2010-02-22
Posts: 43

Posted: Wed, 2011-04-06 19:16

Hi everyone.

Using g3.01 here. I have been having issues uploading files using the flash uploader under Linux (#2038 (IO) errors, but it works fine under windows and firefox, safari or IE). After scouring the Internet, I found a thread or two that simply stated that it simply doesn't work under Linux. That is flat-out horse pucky.

After playing with this for some time, I found that if I disable https on the server (I don't allow unencrypted logins on my box), the uploader works as expected. It is only when my gallery is behind https that the issue arises.

Let me be clear that this NOT a self-signed certificate. I paid for this cert through RapidSSL, and it is verified by GeoTrust, Inc., and it is not expired. It is official. Besides, if it were simply an issue with a self-signed cert, then it wouldn't work under Windows either.

So far, I see this as an issue with the flash player port in Linux doing or not doing something behind the scenes. So... since I don't see Adobe giving a fig about this, the question is: Is there any elegant work-around for this issue? And, is anyone else finding similar issues when using a Linux client over an https connection?

Thank you.

G

nivekiam

Joined: 2002-12-10
Posts: 16504

Posted: Wed, 2011-04-06 19:23

Good to know. Guess I won't go with RapidSSL even though they are cheaper.

I currently have a RapidSSL trial cert setup on my site so I'll see if I can test that in the next day or two.
____________________________________________
Like Gallery? Like the support? Donate now!

grooveman

Joined: 2010-02-22
Posts: 43

Posted: Wed, 2011-04-06 19:35

Quote:

Good to know. Guess I won't go with RapidSSL even though they are cheaper.

Heh. I hope that isn't the only wisdom gained here! ;)

Quote:

I currently have a RapidSSL trial cert setup on my site so I'll see if I can test that in the next day or two.

Thanks, I'd appreciate that!

ramind

Joined: 2007-04-09
Posts: 11

Posted: Sun, 2011-05-08 15:39

Hi,

I get the 2038 error, and also "Server Error 413". It looks like they are related to mod_security.
I have found out the following:

- Errors 2038 and 2038 (IO):
As I found out, this generates an error report in /etc/httpd/logs/modsec_audit.log.
Example:

Quote:

--8cdd7f0a-H--
Message: Pattern match "^([^;\s]+)" at REQUEST_HEADERS:Content-Type. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_30_http_policy.conf"] [line "63"] [id "960010"] [msg "Request content type is not allowed by policy"] [data "application/x-www-form-urlencoded"] [severity "WARNING"] [tag "POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"]
Apache-Handler: php5-script
Stopwatch: 1304864598073779 144139 (1604* 4083 -)
Producer: ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/); core ruleset/2.0.5.
Server: Apache/2.2.17 (Fedora)

This means that the uploader of Gallery3 is sending the server weird stuff in the request.
I commented out the rule which caused this message (which is referenced in the message above - Hint: you must comment out lines 63, 64 and 65).
WARNING: I have no idea if this is a good idea on a public server (my server is only local and development, so it doesn't matter here).

----------------------------------------------------------------------

- HTTPD Error 413:
This comes as a result of having the default (too low) values for uploads set in /etc/httpd/conf.d/mod_security.conf. With this, the "http uploader" module won't work either, it will just stall.
To get rid of this error, you must change (increase) the value of the SecRequestBodyLimit parameter in that file from its default of 128KB to something more realistic - files from current cameras are around 4MB (setting would be 4194304).

Environment:
Fedora FC14 x86_64
Httpd 2.2.17
Gallery 3.0.1
PHP 5.3
Clients: Firefox 3.6.17, Opera 11.10

I hope that this helps.

grooveman

Joined: 2010-02-22
Posts: 43

Posted: Sun, 2011-05-15 20:12

Umm... not so sure this is the same issue ramind...

First, why would it only affect linux clients? It works on Windows just fine. If it were a configuration issue on the server, wouldn't affect all OSes and all browsers?

Second, I cannot find any mention of mod_security on my server. I'm running Debian Lenny. I don't see a mod_security.conf anywhere, and I haven't found any "SecRequestBodyLimit" in any files under /etc via a recursive grep. I have searched via aptitude, and see no mod_security or ModSecurity (or any other variant) and foudn no mention of it. I have tried putting a line in like this "SecRequestBodyLimit 67108864" /etc/apache2/conf.d/security and in apache2.conf directly, but it only errored-out.

I'm just not sure we are talking about the same thing here...

erAck

Joined: 2011-06-22
Posts: 4

Posted: Wed, 2011-06-22 14:48

grooveman wrote:

I found that if I disable https on the server (I don't allow unencrypted logins on my box), the uploader works as expected. It is only when my gallery is behind https that the issue arises.

I confirm that the error occurs on Linux with HTTPS but not with HTTP.

nivekiam

Joined: 2002-12-10
Posts: 16504

Posted: Wed, 2011-06-22 15:03

Who issued your SSL certs?
____________________________________________
Like Gallery? Like the support? Donate now!

grooveman

Joined: 2010-02-22
Posts: 43

Posted: Wed, 2011-06-22 15:38

Hi Niv,

Like I said in that pm I sent you a while back, I'm using rapid ssl through GEO Trust. Purchased through Reliable Site.

I would be interested in knowing wath erAk uses...

erAck

Joined: 2011-06-22
Posts: 4

Posted: Wed, 2011-06-22 21:32

Validity/trust of the certificate might indeed be a problem. I use a self-signed certificate that I explicitly accepted in Firefox, maybe the Flash stuff bails out on that.

grooveman

Joined: 2010-02-22
Posts: 43

Posted: Wed, 2011-06-22 22:12

This has to be a problem with flash for linux... I just updated my flash about 5 days ago, and it suddenly works. So... what version of flash are you running? I'm running: Shockwave Flash 10.3 r181, and firefox 3.6.17.

guywithcable

Joined: 2011-07-22
Posts: 1

Posted: Fri, 2011-07-22 22:34

On this same note, uploading wouldn't work on my site either. After checking the apache logs and seeing a 401 error I realized it was because my site was using HTTP authentication. Apparently the flash uploader can't do HTTP authentication. It worked perfectly once I disabled HTTP authentication.

I don't know if any of this helped effect the 2038 problem, but here's my setup:

Ubuntu Server 10.10
Linux *** 2.6.35-30-server #54-Ubuntu SMP Tue Jun 7 20:13:05 UTC 2011 x86_64 GNU/Linux
PHP 5.3.3-1ubuntu9.5 with Suhosin-Patch (built: May 3 2011 00:48:48)
Server version: Apache/2.2.16 (Ubuntu)
Server built: Nov 18 2010 21:17:43
OpenSSL 0.9.8o 01 Jun 2010

(SSL is enabled.)
Certificate Issuer:
CN = Starfield Secure Certification Authority
OU = http://certificates.starfieldtech.com/repository
O = "Starfield Technologies, Inc."
L = Scottsdale
ST = Arizona
C = US

floridave

Joined: 2003-12-22
Posts: 27300

Posted: Sat, 2011-07-23 00:22

guywithcable,
The docs have "Don't use self signed SSL certificates. " should that be expanded?

Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team

grooveman Joined: 2010-02-22 Posts: 43	Posted: Wed, 2011-04-06 19:16
	Hi everyone. Using g3.01 here. I have been having issues uploading files using the flash uploader under Linux (#2038 (IO) errors, but it works fine under windows and firefox, safari or IE). After scouring the Internet, I found a thread or two that simply stated that it simply doesn't work under Linux. That is flat-out horse pucky. After playing with this for some time, I found that if I disable https on the server (I don't allow unencrypted logins on my box), the uploader works as expected. It is only when my gallery is behind https that the issue arises. Let me be clear that this NOT a self-signed certificate. I paid for this cert through RapidSSL, and it is verified by GeoTrust, Inc., and it is not expired. It is official. Besides, if it were simply an issue with a self-signed cert, then it wouldn't work under Windows either. So far, I see this as an issue with the flash player port in Linux doing or not doing something behind the scenes. So... since I don't see Adobe giving a fig about this, the question is: Is there any elegant work-around for this issue? And, is anyone else finding similar issues when using a Linux client over an https connection? Thank you. G
	XUser login Username: * Password: * Create new account Request new password
nivekiam Joined: 2002-12-10 Posts: 16504	Posted: Wed, 2011-04-06 19:23
	Good to know. Guess I won't go with RapidSSL even though they are cheaper. I currently have a RapidSSL trial cert setup on my site so I'll see if I can test that in the next day or two. ____________________________________________ Like Gallery? Like the support? Donate now!

grooveman Joined: 2010-02-22 Posts: 43	Posted: Wed, 2011-04-06 19:35
	Quote: Good to know. Guess I won't go with RapidSSL even though they are cheaper. Heh. I hope that isn't the only wisdom gained here! ;) Quote: I currently have a RapidSSL trial cert setup on my site so I'll see if I can test that in the next day or two. Thanks, I'd appreciate that!

ramind Joined: 2007-04-09 Posts: 11	Posted: Sun, 2011-05-08 15:39
	Hi, I get the 2038 error, and also "Server Error 413". It looks like they are related to mod_security. I have found out the following: - Errors 2038 and 2038 (IO): As I found out, this generates an error report in /etc/httpd/logs/modsec_audit.log. Example: Quote: --8cdd7f0a-H-- Message: Pattern match "^([^;\s]+)" at REQUEST_HEADERS:Content-Type. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_30_http_policy.conf"] [line "63"] [id "960010"] [msg "Request content type is not allowed by policy"] [data "application/x-www-form-urlencoded"] [severity "WARNING"] [tag "POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"] Apache-Handler: php5-script Stopwatch: 1304864598073779 144139 (1604* 4083 -) Producer: ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/); core ruleset/2.0.5. Server: Apache/2.2.17 (Fedora) This means that the uploader of Gallery3 is sending the server weird stuff in the request. I commented out the rule which caused this message (which is referenced in the message above - Hint: you must comment out lines 63, 64 and 65). WARNING: I have no idea if this is a good idea on a public server (my server is only local and development, so it doesn't matter here). ---------------------------------------------------------------------- - HTTPD Error 413: This comes as a result of having the default (too low) values for uploads set in /etc/httpd/conf.d/mod_security.conf. With this, the "http uploader" module won't work either, it will just stall. To get rid of this error, you must change (increase) the value of the SecRequestBodyLimit parameter in that file from its default of 128KB to something more realistic - files from current cameras are around 4MB (setting would be 4194304). Environment: Fedora FC14 x86_64 Httpd 2.2.17 Gallery 3.0.1 PHP 5.3 Clients: Firefox 3.6.17, Opera 11.10 I hope that this helps.

grooveman Joined: 2010-02-22 Posts: 43	Posted: Sun, 2011-05-15 20:12
	Umm... not so sure this is the same issue ramind... First, why would it only affect linux clients? It works on Windows just fine. If it were a configuration issue on the server, wouldn't affect all OSes and all browsers? Second, I cannot find any mention of mod_security on my server. I'm running Debian Lenny. I don't see a mod_security.conf anywhere, and I haven't found any "SecRequestBodyLimit" in any files under /etc via a recursive grep. I have searched via aptitude, and see no mod_security or ModSecurity (or any other variant) and foudn no mention of it. I have tried putting a line in like this "SecRequestBodyLimit 67108864" /etc/apache2/conf.d/security and in apache2.conf directly, but it only errored-out. I'm just not sure we are talking about the same thing here...

erAck Joined: 2011-06-22 Posts: 4	Posted: Wed, 2011-06-22 14:48
	grooveman wrote: I found that if I disable https on the server (I don't allow unencrypted logins on my box), the uploader works as expected. It is only when my gallery is behind https that the issue arises. I confirm that the error occurs on Linux with HTTPS but not with HTTP.

nivekiam Joined: 2002-12-10 Posts: 16504	Posted: Wed, 2011-06-22 15:03
	Who issued your SSL certs? ____________________________________________ Like Gallery? Like the support? Donate now!

grooveman Joined: 2010-02-22 Posts: 43	Posted: Wed, 2011-06-22 15:38
	Hi Niv, Like I said in that pm I sent you a while back, I'm using rapid ssl through GEO Trust. Purchased through Reliable Site. I would be interested in knowing wath erAk uses...

erAck Joined: 2011-06-22 Posts: 4	Posted: Wed, 2011-06-22 21:32
	Validity/trust of the certificate might indeed be a problem. I use a self-signed certificate that I explicitly accepted in Firefox, maybe the Flash stuff bails out on that.

grooveman Joined: 2010-02-22 Posts: 43	Posted: Wed, 2011-06-22 22:12
	This has to be a problem with flash for linux... I just updated my flash about 5 days ago, and it suddenly works. So... what version of flash are you running? I'm running: Shockwave Flash 10.3 r181, and firefox 3.6.17.

guywithcable Joined: 2011-07-22 Posts: 1	Posted: Fri, 2011-07-22 22:34
	On this same note, uploading wouldn't work on my site either. After checking the apache logs and seeing a 401 error I realized it was because my site was using HTTP authentication. Apparently the flash uploader can't do HTTP authentication. It worked perfectly once I disabled HTTP authentication. I don't know if any of this helped effect the 2038 problem, but here's my setup: Ubuntu Server 10.10 Linux *** 2.6.35-30-server #54-Ubuntu SMP Tue Jun 7 20:13:05 UTC 2011 x86_64 GNU/Linux PHP 5.3.3-1ubuntu9.5 with Suhosin-Patch (built: May 3 2011 00:48:48) Server version: Apache/2.2.16 (Ubuntu) Server built: Nov 18 2010 21:17:43 OpenSSL 0.9.8o 01 Jun 2010 (SSL is enabled.) Certificate Issuer: CN = Starfield Secure Certification Authority OU = http://certificates.starfieldtech.com/repository O = "Starfield Technologies, Inc." L = Scottsdale ST = Arizona C = US

floridave Joined: 2003-12-22 Posts: 27300	Posted: Sat, 2011-07-23 00:22
	guywithcable, The docs have "Don't use self signed SSL certificates. " should that be expanded? Dave _____________________________________________ Blog & G2 \|\| floridave - Gallery Team

#2038 - A new twist...

XUser login