https:// sites are not working (rev 1009)

Thanks for filing a separate bug. As I told you, this is probably an know issue with the SSL certificates that libcURL uses.

Replying to kiranps:

https:// sites are not working (rev 1009). bin/owb https://www.verisign.com does not work (Progress reaches 100 instantly). Yahoo mail is still not logging in. I also have set export WEBKIT_IGNORE_SSL_ERRORS=1

This trick only works in DEBUG mode. To reduce the problem, you can export CURL_DEBUG=1 which should display what curl is doing (again it only works in DEBUG mode).

When I traced using gdb this function was returning false for http urls. WebFrameLoaderClient::representationExistsForURLScheme

I think it is unlikely that it is the cause of your error: Qt, Gtk and us have not implemented this method and all return false. Also they all support SSL sites.

Here is the trace. I am using a squid proxy at 192.168.0.124:8080. curl version 7.19.5 (x86_64-unknown-linux-gnu) curl command-line app is able to download the url.

(/tmp/trunk/BAL/Graphics/WebCore/SDL/BCGraphicsContextSDL.cpp:758 void WebCore::GraphicsContext::setCompositeOperation(WebCore::CompositeOperator)) * About to connect() to proxy 192.168.0.124 port 8080 (#0) * Trying 192.168.0.124... * Connected to 192.168.0.124 (192.168.0.124) port 8080 (#0) * Establish HTTP proxy tunnel to www.verisign.com:443

CONNECT www.verisign.com:443 HTTP/1.0

Host: www.verisign.com:443 Proxy-Connection: Keep-Alive User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/525.1+ (KHTML, like Gecko, Safari/525.1+) Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

< HTTP/1.0 200 Connection established < progress : 100 * Proxy replied OK to CONNECT request * CAfile: /etc/pki/tls/certs/ca-bundle.crt

CApath: none

* Issuer certificate is invalid: 'CN=VeriSign Class 3 Extended Validation SSL SGC CA,OU=Terms of use at https://www.verisign.com/rpa (c)06,OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US' * SSL certificate verify ok. * SSL connection using SSL_RSA_WITH_RC4_128_MD5 * Server certificate: * subject: CN=www.verisign.com,OU=Production Security Services,O="VeriSign, Inc.",OID.2.5.4.9=487 East Middlefield Road,L=Mountain View,ST=California,postalCode=94043,C=US,serialNumber=2497886,OID.2.5.4.15="V1.0, Clause 5.(b)",OID.1.3.6.1.4.1.311.60.2.1.2=Delaware,OID.1.3.6.1.4.1.311.60.2.1.3=US * start date: Apr 22 00:00:00 2009 GMT * expire date: May 09 23:59:59 2010 GMT * common name: www.verisign.com * issuer: CN=VeriSign Class 3 Extended Validation SSL SGC CA,OU=Terms of use at https://www.verisign.com/rpa (c)06,OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US * Connected to 192.168.0.124 (192.168.0.124) port 8080 (#0)

GET / HTTP/1.1

Host: www.verisign.com Accept-Encoding: deflate, gzip User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/525.1+ (KHTML, like Gecko, Safari/525.1+) Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

< HTTP/1.1 200 OK * Failed writing header * Closing connection #0

I see two differences between my trace and yours:

* Proxy replied OK to CONNECT request

You are using a proxy.

* CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * Issuer certificate is invalid: 'CN=VeriSign Class 3 Extended Validation SSL SGC

CA,OU=Terms of use at https://www.verisign.com/rpa (c)06,OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US'

The certificate is wrongly rejected.

Normally I would have said to use WEBKIT_IGNORE_SSL_ERRORS that would disable all certificate's verification in WebKit, but you have said you have already tried it. So I guess the issue is somehow related to your proxy or your machine. Could you try testing without any proxy and WEBKIT_IGNORE_SSL_ERRORS set? Can you have a look at the content of your certificate file (/etc/pki/tls/certs/ca-bundle.crt)?

This same setup used to work here I have attached the trace of rev 916 on the same machine with same setup and here it works without any issues.

(/tmp/gTeleBrowseServer/owb/BAL/Graphics/WebCore/SDL/BCGraphicsContextSDL.cpp:767 void WebCore::GraphicsContext::setCompositeOperation(WebCore::CompositeOperator)) * STATE: INIT => CONNECT handle 0x9e1568; (connection #-5000) * About to connect() to proxy 192.168.0.124 port 8080 (#0) * Trying 192.168.0.124... * STATE: CONNECT => WAITCONNECT handle 0x9e1568; (connection #0) * Connected to 192.168.0.124 (192.168.0.124) port 8080 (#0) * Establish HTTP proxy tunnel to www.verisign.com:443

CONNECT www.verisign.com:443 HTTP/1.1

Host: www.verisign.com:443 Proxy-Connection: Keep-Alive User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/525.1+ (KHTML, like Gecko, Safari/525.1+) Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

* STATE: WAITCONNECT => WAITPROXYCONNECT handle 0x9e1568; (connection #0) * Multi mode finished polling for response from proxy CONNECT.< HTTP/1.0 200 Connection established < decidePolicyForMIMEType https://www.verisign.com/ []

* Proxy replied OK to CONNECT request * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt

CApath: none

* STATE: WAITPROXYCONNECT => WAITCONNECT handle 0x9e1568; (connection #0) * Connected to 192.168.0.124 (192.168.0.124) port 8080 (#0) * STATE: WAITCONNECT => PROTOCONNECT handle 0x9e1568; (connection #0) * SSL connection using RC4-MD5 * Server certificate: * subject: 1.3.6.1.4.1.311.60.2.1.3=US, 1.3.6.1.4.1.311.60.2.1.2=Delaware, 2.5.4.15=V1.0, Clause 5.(b), serialNumber=2497886, C=US, postalCode=94043, ST=California, L=Mountain View, streetAddress=487 East Middlefield Road, O=VeriSign, Inc., OU=Production Security Se * start date: 2009-04-22 00:00:00 GMT * expire date: 2010-05-09 23:59:59 GMT * common name: www.verisign.com (matched) * issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL SGC CA * SSL certificate verify ok. * STATE: PROTOCONNECT => DO handle 0x9e1568; (connection #0)

GET / HTTP/1.1

Host: www.verisign.com Accept-Encoding: deflate, gzip User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/525.1+ (KHTML, like Gecko, Safari/525.1+) Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

* STATE: DO => DO_DONE handle 0x9e1568; (connection #0) * STATE: DO_DONE => WAITPERFORM handle 0x9e1568; (connection #0) * STATE: WAITPERFORM => PERFORM handle 0x9e1568; (connection #0) * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 200 OK < Server: Netscape-Enterprise/4.1 < Date: Mon, 22 Jun 2009 09:24:02 GMT * Added cookie v1st="4A3F4DB343C01EDD" for domain verisign.com, path /, expire 1582122480 < Set-Cookie: v1st=4A3F4DB343C01EDD; path=/; expires=Wed, 19 Feb 2020 14:28:00 GMT; domain=.verisign.com < Content-type: text/html < Connection: close decidePolicyForMIMEType https://www.verisign.com/ [text/html]

< progress : 11 * STATE: INIT => CONNECT handle 0xaa8de8; (connection #-5000) * STATE: INIT => CONNECT handle 0xaa91a8; (connection #-5000) * STATE: INIT => CONNECT handle 0x9d83d8; (connection #-5000) * STATE: INIT => CONNECT handle 0xaa9998; (connection #-5000) * About to connect() to proxy 192.168.0.124 port 8080 (#1) .... .... ....

It seems that the 2 traces were not generated with the same lib (one is a debug build and the other is not). Are you sure it is exactly the same environment?

Independently of the libcurl change I just mentioned, your best bet would be to find out which revision has brought the regression. This would help us find out what the issue is (I have tried to see the changes between the trunk and r916 but I failed to pinpoint the one that would impact this bug).

I finally had some time to look at why https is not working thru the proxy. When I run ./bin/owb https://www.verisign.com the certificate store is being found but the MIME type is empty so WebFrameLoaderClient::canShowMIMEType is returning false, which is used by MainResourceLoader::continueAfterContentPolicy and is aborting the connection in progress.

When I comment out MainResourceLoader.cpp:209 to 215, the https URLs are loading properly.

FIX: WebCore\loader\MainResourceLoader.cpp:206

case PolicyUse: {

// Prevent remote web archives from loading because they can claim to be from any domain and thus avoid cross-domain security checks (4120255). bool isRemoteWebArchive = equalIgnoringCase("application/x-webarchive", mimeType) && !m_substituteData.isValid() && !url.isLocalFile();

//HTTPS over proxy Fix:Start if (!isRemoteWebArchive) {

if (url.protocolIs("https")&&(mimeType.length()==0)) {

break;

}

} //HTTPS over proxy Fix:End

if (!frameLoader()->canShowMIMEType(mimeType) isRemoteWebArchive) {

frameLoader()->cannotShowMIMEType(r); // Check reachedTerminalState since the load may have already been cancelled inside of _handleUnimplementablePolicyWithErrorCode::. if (!reachedTerminalState())

stopLoadingForPolicyChange();

return;

}

FIX: WebCore\loader\MainResourceLoader.cpp:206 (With code formatting, sorry about the prev post)

    case PolicyUse: {
        // Prevent remote web archives from loading because they can claim to be from any domain and thus avoid cross-domain security checks (4120255).
        bool isRemoteWebArchive = equalIgnoringCase("application/x-webarchive", mimeType) && !m_substituteData.isValid() && !url.isLocalFile();

		//HTTPS over proxy Fix:Start
		if (!isRemoteWebArchive)
		{
			if (url.protocolIs("https")&&(mimeType.length()==0))
			{
				break;
			}
		}
		//HTTPS over proxy Fix:End

I finally had some time to look at why https is not working thru the proxy. When I run ./bin/owb https://www.verisign.com the certificate store is being found but the MIME type is empty so WebFrameLoaderClient::canShowMIMEType is returning false, which is used by MainResourceLoader::continueAfterContentPolicy and is aborting the connection in progress.

Thanks for investigating this further.

When I comment out MainResourceLoader.cpp:209 to 215, the https URLs are loading properly.

I am not sure you are patching the consequence and not the cause here. What would be important to understand is why is the MIME type empty. Usually when the content-type header is empty, the browser will do a content sniff to determine what is the real MIME type and fail loading after doing it. Looking at your previous curl trace, I could not make sense here. Could you paste a complete curl trace of the failing case so that we have a way to compare to a normal trace (preferably from a non-debug libcURL)? If you want to debug yourself, you could have a look at the value of the "Content-Type" header when you fail (a way is to set a break point in extractMIMETypeFromMediaType (network/HTTPParsers.cpp:145)).

For me HTTPParsers.cpp is even not even getting compiled / called. I am using curl for network.

When I traced it, MainResourceLoader::continueAfterContentPolicy was explicitly aborting the connection (calling stopLoadingForPolicyChange) because of the MIME issue.

cmake -D ENABLE_DEBUG="ON"  ..

I am using Squid Proxy on running on a linux box.

Here is the Curl Debug Log


bin/owb "https://www.verisign.com/getseal?at=0&&sealid=2&dn=WWW.VERISIGN.COM&aff=VeriSignAdministration&lang=en"
Staring OWB using 640x480
UNIMPLEMENTED:
(/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:943 virtual void WebFrameLoaderClient::provisionalLoadStarted())
UNIMPLEMENTED:
(/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:896 virtual void WebFrameLoaderClient::setMainFrameDocumentReady(bool))
UNIMPLEMENTED:
(/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:858 virtual void WebFrameLoaderClient::setCopiesOnScroll())
UNIMPLEMENTED:
(/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:953 virtual void WebFrameLoaderClient::prepareForDataSourceReplacement())
UNIMPLEMENTED:
(/owb/BAL/Widgets/WebCore/SDL/BCWidgetSDL.cpp:98 virtual void WebCore::Widget::show())
UNIMPLEMENTED:
(/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:1187 virtual WebCore::String WebFrameLoaderClient::overrideMediaType() const)
UNIMPLEMENTED:
(/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:853 virtual void WebFrameLoaderClient::forceLayoutForNonHTML())
UNIMPLEMENTED:
(/owb/BAL/Widgets/WebCore/SDL/BCScrollbarThemeSDL.cpp:65 virtual int WebCore::ScrollbarThemeBal::scrollbarThickness(WebCore::ScrollbarControlSize))
UNIMPLEMENTED:
(/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:922 virtual bool WebFrameLoaderClient::representationExistsForURLScheme(const WebCore::String&) const)




 MainResourceLoader::loadNow https://www.verisign.com/getseal?at=0&&sealid=2&dn=WWW.VERISIGN.COM&aff=VeriSignAdministration&lang=en




UNIMPLEMENTED:
(/owb/BAL/Graphics/WebCore/SDL/BCGraphicsContextSDL.cpp:768 void WebCore::GraphicsContext::setCompositeOperation(WebCore::CompositeOperator))
* STATE: INIT => CONNECT handle 0x18fad68; (connection #-5000)
* About to connect() to proxy 192.168.0.124 port 8080 (#0)
*   Trying 192.168.0.124... * STATE: CONNECT => WAITCONNECT handle 0x18fad68; (connection #0)
* Connected to 192.168.0.124 (192.168.0.124) port 8080 (#0)
* Establish HTTP proxy tunnel to www.verisign.com:443
> CONNECT www.verisign.com:443 HTTP/1.1
Host: www.verisign.com:443
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/525.1+ (KHTML, like Gecko, Safari/525.1+)
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

* STATE: WAITCONNECT => WAITPROXYCONNECT handle 0x18fad68; (connection #0)
* Multi mode finished polling for response from proxy CONNECT.< HTTP/1.0 200 Connection established
<
decidePolicyForMIMEType [https://www.verisign.com/getseal?at=0&&sealid=2&dn=WWW.VERISIGN.COM&aff=VeriSignAdministration&lang=en] [] canShowMIMEType[1]
UNIMPLEMENTED:
(/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:996 virtual WebCore::ResourceError WebFrameLoaderClient::cannotShowMIMETypeError(const WebCore::ResourceResponse&))
progress : 100
* Proxy replied OK to CONNECT request
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* STATE: WAITPROXYCONNECT => WAITCONNECT handle 0x18fad68; (connection #0)
* Connected to 192.168.0.124 (192.168.0.124) port 8080 (#0)
* STATE: WAITCONNECT => PROTOCONNECT handle 0x18fad68; (connection #0)
* SSL connection using RC4-MD5
* Server certificate:
*        subject: 1.3.6.1.4.1.311.60.2.1.3=US, 1.3.6.1.4.1.311.60.2.1.2=Delaware, 2.5.4.15=V1.0, Clause 5.(b), serialNumber=2497886, C=US, postalCode=94043, ST=California, L=Mountain View, streetAddress=487 East Middlefield Road, O=VeriSign, Inc., OU=Production Security Se
*        start date: 2009-04-22 00:00:00 GMT
*        expire date: 2010-05-09 23:59:59 GMT
*        common name: www.verisign.com (matched)
*        issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL SGC CA
*        SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x18fad68; (connection #0)
> GET /getseal?at=0&&sealid=2&dn=WWW.VERISIGN.COM&aff=VeriSignAdministration&lang=en HTTP/1.1
Host: www.verisign.com
Accept-Encoding: deflate, gzip
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/525.1+ (KHTML, like Gecko, Safari/525.1+)
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

* STATE: DO => DO_DONE handle 0x18fad68; (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x18fad68; (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x18fad68; (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 404 Not found
* Failed writing header
* Closing connection #0
* STATE: PERFORM => COMPLETED handle 0x18fad68; (connection #-5000)
^Cstats about cache:
        images: count=0 - size=0 - liveSize=0 - decodedSize=0
        cssStyleSheets: count=0 - size=0 - liveSize=0 - decodedSize=0
        scripts: count=0 - size=0 - liveSize=0 - decodedSize=0
        fonts: count=0 - size=0 - liveSize=0 - decodedSize=0
UNIMPLEMENTED:
(/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:863 virtual void WebFrameLoaderClient::detachedFromParent2())
UNIMPLEMENTED:
(/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:868 virtual void WebFrameLoaderClient::detachedFromParent3())

[root@localhost build]# bin/owb https://www.verisign.com/
Staring OWB using 640x480
UNIMPLEMENTED:
(/ganesh/gTeleBrowseServer/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:943 virtual void WebFrameLoaderClient::provisionalLoadStarted())
UNIMPLEMENTED:
(/ganesh/gTeleBrowseServer/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:896 virtual void WebFrameLoaderClient::setMainFrameDocumentReady(bool))
UNIMPLEMENTED:
(/ganesh/gTeleBrowseServer/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:858 virtual void WebFrameLoaderClient::setCopiesOnScroll())
UNIMPLEMENTED:
(/ganesh/gTeleBrowseServer/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:953 virtual void WebFrameLoaderClient::prepareForDataSourceReplacement())
UNIMPLEMENTED:
(/ganesh/gTeleBrowseServer/owb/BAL/Widgets/WebCore/SDL/BCWidgetSDL.cpp:98 virtual void WebCore::Widget::show())
UNIMPLEMENTED:
(/ganesh/gTeleBrowseServer/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:1187 virtual WebCore::String WebFrameLoaderClient::overrideMediaType() const)
UNIMPLEMENTED:
(/ganesh/gTeleBrowseServer/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:853 virtual void WebFrameLoaderClient::forceLayoutForNonHTML())
UNIMPLEMENTED:
(/ganesh/gTeleBrowseServer/owb/BAL/Widgets/WebCore/SDL/BCScrollbarThemeSDL.cpp:65 virtual int WebCore::ScrollbarThemeBal::scrollbarThickness(WebCore::ScrollbarControlSize))
UNIMPLEMENTED:
(/ganesh/gTeleBrowseServer/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:922 virtual bool WebFrameLoaderClient::representationExistsForURLScheme(const WebCore::String&) const)




 MainResourceLoader::loadNow https://www.verisign.com/



UNIMPLEMENTED:
(/ganesh/gTeleBrowseServer/owb/BAL/Graphics/WebCore/SDL/BCGraphicsContextSDL.cpp:768 void WebCore::GraphicsContext::setCompositeOperation(WebCore::CompositeOperator))
* STATE: INIT => CONNECT handle 0x25ddc38; (connection #-5000)
* About to connect() to proxy 192.168.0.124 port 8080 (#0)
*   Trying 192.168.0.124... * STATE: CONNECT => WAITCONNECT handle 0x25ddc38; (connection #0)
* Connected to 192.168.0.124 (192.168.0.124) port 8080 (#0)
* Establish HTTP proxy tunnel to www.verisign.com:443
> CONNECT www.verisign.com:443 HTTP/1.1
Host: www.verisign.com:443
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/525.1+ (KHTML, like Gecko, Safari/525.1+)
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

* STATE: WAITCONNECT => WAITPROXYCONNECT handle 0x25ddc38; (connection #0)
* Multi mode finished polling for response from proxy CONNECT.< HTTP/1.0 200 Connection established
<
decidePolicyForMIMEType [https://www.verisign.com/] [] canShowMIMEType[1]
UNIMPLEMENTED:
(/ganesh/gTeleBrowseServer/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:996 virtual WebCore::ResourceError WebFrameLoaderClient::cannotShowMIMETypeError(const WebCore::ResourceResponse&))
progress : 100
* Proxy replied OK to CONNECT request
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* STATE: WAITPROXYCONNECT => WAITCONNECT handle 0x25ddc38; (connection #0)
* Connected to 192.168.0.124 (192.168.0.124) port 8080 (#0)
* STATE: WAITCONNECT => PROTOCONNECT handle 0x25ddc38; (connection #0)
* SSL connection using RC4-MD5
* Server certificate:
*        subject: 1.3.6.1.4.1.311.60.2.1.3=US, 1.3.6.1.4.1.311.60.2.1.2=Delaware, 2.5.4.15=V1.0, Clause 5.(b), serialNumber=2497886, C=US, postalCode=94043, ST=California, L=Mountain View, streetAddress=487 East Middlefield Road, O=VeriSign, Inc., OU=Production Security Se
*        start date: 2009-04-22 00:00:00 GMT
*        expire date: 2010-05-09 23:59:59 GMT
*        common name: www.verisign.com (matched)
*        issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL SGC CA
*        SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x25ddc38; (connection #0)
> GET / HTTP/1.1
Host: www.verisign.com
Accept-Encoding: deflate, gzip
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/525.1+ (KHTML, like Gecko, Safari/525.1+)
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

* STATE: DO => DO_DONE handle 0x25ddc38; (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x25ddc38; (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x25ddc38; (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
* Failed writing header
* Closing connection #0
* STATE: PERFORM => COMPLETED handle 0x25ddc38; (connection #-5000)

Replying to kiranps:

For me HTTPParsers.cpp is even not even getting compiled / called. I am using curl for network.

My bad, the right file is BAL/Facilities/WebCore/WK/BCHTTPParsersWK.cpp. I stated the one from WebKit. FYI, this file is cross-platform and used by most - if not all - network backends.

I have had a look at your second paste (the first one is not usable).

> GET / HTTP/1.1
Host: www.verisign.com
Accept-Encoding: deflate, gzip
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/525.1+ (KHTML, like Gecko, Safari/525.1+)
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

* STATE: DO => DO_DONE handle 0x25ddc38; (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x25ddc38; (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x25ddc38; (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
* Failed writing header

How the response is handled is very strange. Usually, there are several headers after the status line ("HTTP/1.1 200 OK"). Here thought, it seems that WebKit has canceled the connection (which is the only way to explain the "Failed writing header" displayed by cURL) after the status line is received. I don't see what is culprit in this case by I sense that something fishy must happen in the headerCallback in BAL/Network/WebCore/Curl/BCResourceHandleManagerCurl.cpp. Check whether it calls didReceivedReponse on the ResourceHandleClient.

You were right jchaffraix I put a print in headerCallback, and I think owb is using the "HTTP/1.0 200 Connection established" header (from proxy) instead of the actual one from the webserver.

{{

size_t totalSize = size * nmemb; ResourceHandleClient* client = d->client();

String header(static_cast<const char*>(ptr), totalSize);

printf("TRACE -> headerCallback:%s\n",header.utf8().data());

/*

• a) We can finish and send the ResourceResponse
• b) We will add the current header to the HTTPHeaderMap of the ResourceResponse *
• The HTTP standard requires to use \r\n but for compatibility it recommends to
• accept also \n. */

}}

* STATE: INIT => CONNECT handle 0x1144058; (connection #-5000)
* About to connect() to proxy 192.168.0.124 port 8080 (#0)
*   Trying 192.168.0.124... * STATE: CONNECT => WAITCONNECT handle 0x1144058; (connection #0)
* Connected to 192.168.0.124 (192.168.0.124) port 8080 (#0)
* Establish HTTP proxy tunnel to www.verisign.com:443
> CONNECT www.verisign.com:443 HTTP/1.1
Host: www.verisign.com:443
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/525.1+ (KHTML, like Gecko, Safari/525.1+)
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

* STATE: WAITCONNECT => WAITPROXYCONNECT handle 0x1144058; (connection #0)
* Multi mode finished polling for response from proxy CONNECT.< HTTP/1.0 200 Connection established
TRACE -> headerCallback:HTTP/1.0 200 Connection established

<
TRACE -> headerCallback:

decidePolicyForMIMEType [https://www.verisign.com/] [] canShowMIMEType[1]
UNIMPLEMENTED:
(/ganesh/gTeleBrowseServer/owb/WebKit/OrigynWebBrowser/WebCoreSupport/WebFrameLoaderClient.cpp:996 virtual WebCore::ResourceError WebFrameLoaderClient::cannotShowMIMETypeError(const WebCore::ResourceResponse&))
progress : 100

* Proxy replied OK to CONNECT request
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* STATE: WAITPROXYCONNECT => WAITCONNECT handle 0x1144058; (connection #0)
* Connected to 192.168.0.124 (192.168.0.124) port 8080 (#0)
* STATE: WAITCONNECT => PROTOCONNECT handle 0x1144058; (connection #0)
* SSL connection using RC4-MD5
* Server certificate:
*        subject: 1.3.6.1.4.1.311.60.2.1.3=US, 1.3.6.1.4.1.311.60.2.1.2=Delaware, 2.5.4.15=V1.0, Clause 5.(b), serialNumber=2497886, C=US, postalCode=94043, ST=California, L=Mountain View, streetAddress=487 East Middlefield Road, O=VeriSign, Inc., OU=Production Security Se
*        start date: 2009-04-22 00:00:00 GMT
*        expire date: 2010-05-09 23:59:59 GMT
*        common name: www.verisign.com (matched)
*        issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL SGC CA
*        SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x1144058; (connection #0)
> GET / HTTP/1.1
Host: www.verisign.com
Accept-Encoding: deflate, gzip
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/525.1+ (KHTML, like Gecko, Safari/525.1+)
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

* STATE: DO => DO_DONE handle 0x1144058; (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x1144058; (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x1144058; (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
* Failed writing header
* Closing connection #0
* STATE: PERFORM => COMPLETED handle 0x1144058; (connection #-5000)

Replying to kiranps:

You were right jchaffraix I put a print in headerCallback, and I think owb is using the "HTTP/1.0 200 Connection established" header (from proxy) instead of the actual one from the webserver.

Right, judging from the trace you put, it seems to be the case. I guess that the http sites are working so it means it is a difference in behaviour in libcURL. As it is not normal that we receive the communication from the proxy, I would say it is worth raising the issue on the libcURL mailing list (http://cool.haxx.se/mailman/listinfo/curl-library). If you can have a tiny curl example (just using a program that uses the headerCallback should be close of how we work), it would certainly help.

Since this is not a webkit issue and a CURL issue we can probably close it.

decoration Changed 1 year ago by admin

bathtub Changed 1 year ago by admin

solar system Changed 1 year ago by admin

stair parts Changed 1 year ago by admin

solar supply Changed 1 year ago by admin