458996 - Semantic error in nsHttpConnection::SupportsPipelining() function

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Albert]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

Prerequisite configurations are

/* http prefs */
pref("network.http.pipelining", true);
pref("network.http.pipelining.ssl", true);
pref("network.http.proxy.pipelining", true);
pref("network.http.pipelining.maxrequests" , 6);
pref("network.http.keep-alive.timeout", 10);
pref("network.http.max-connections", 4);
pref("network.http.max-connections-per-server", 4);
pref("network.http.max-persistent-connections-per-server", 4);
pref("network.http.max-persistent-connections-per-proxy", 4);
pref("network.proxy.http","xxx.xxx.xxx.xxx");
pref("network.proxy.http_port",8080);
pref("network.proxy.ssl","xxx.xxx.xxx.xxx");
pref("network.proxy.ssl_port",443);


I have observed that when using proxy server through Vodafone Network, I have connected a specific site by i780 Samsung mobile target.
I would never see pipelining while connecting a specific site.


I have checked nsHttpConnection::SupportsPipelining() in nsHttpConnection.cpp

I think that this function has a semantic error.

According to source flow in this funtion.
If a connection supports UsingHttpProxy which is "mConnInfo->UsingHttpProxy()", this function returns TRUE.
Actually, it must be a normal pipelining.

But suppose a site does not support pipelining, this funtion returns TRUE because UsingHttpProxy is available.
Checking server sites is below first return operation in a currently source.
 
This creates a couple problems
* Regardless of server sites which are supporting pipelining, only checking UsingHttpProxy effects user to misunderstand operating.
* If server does not support pipelining, the browser may be blocking.

I think that return operations must be changed, it's like below

+	PRBool rv = PR_FALSE ;

    // XXX there should be a strict mode available that disables this
    // blacklisting.

    // assuming connection is HTTP/1.1 with keep-alive enabled
    if (mConnInfo->UsingHttpProxy() && !mConnInfo->UsingSSL()) {
        // XXX check for bad proxy servers...
-	 return PR_TRUE;
+        rv = PR_TRUE;
    }
 
    .....
    // ok, let's allow pipelining to this server
+   return rv;


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Albert]

Attachment: Return operations changed in flow

Comment 2

[Stuart Parmenter]

pat, can you take a look at this?

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

Hm, why was the code wrong? If a proxy server is used, then you don't make a connection to the server, just to the proxy. So there is no need/point in checking for the Server header.

Comment 4

[Patrick McManus [:mcmanus]]

I agree with Christian.

pipelining, like other connection properties, is hop-top-hop not end-to-end. The code currently says that if you are connected to a proxy then do not consider the origin server when deciding when to pipeline because that connection has now become the responsibility of the intermediary. 

This is consistent with the other attributes used to determine pipelining - chiefly the HTTP version level of the response as seen by the client which is set by the intermediary, not the origin server. (e.g. the intermediary may upgrade a HTTP/1.0 response to be a 1.1 response and then would be required to take pipelined requests as input which it would need to de-pipeline before handing to the server.. depending on where the high latency hops are in the network, this could be a very effective strategy).

I don't see a need for this change.

Albert, I am confused by your comment "I would never see pipelining while connecting a specific site" whereas the rest of the bug (and your patch) seems to be oriented around "too liberal pipelining".

Comment 5

[Albert]

We have and say very different network concept each other, I think.
Have you heard LiMo Foundation or Data networking which is based on TAPI or Modem functions?

I stated this issue when connecting sites through a specific network by using a mobile target.
A specific network is given by service providers, for example Vodafone, Orange and Cigular.
If we have to connect an internet by using a mobile target in GPRS(General Packet Radio Service)/WCDMA network,
we must use a given specific proxy address and port by the items and contents which are internet, mms, email and VOD.
A proxy address and a port are depend on the service providers and the telecomunications.


I know Fennec is heading to keep up with the mobile environment.
Let me notify you of "Reference 3GPP TS 23.060 GPRS Service description"
To examine this process I said, first connecting PDP(Packet Data Protocol) activation, second using necko nsSocketTransport functions.

Based on my job and experience, the mobile environment is very different from PC.
I think we who are developing a mobile browser may refer to PDP and GPRS which is supporting in both 2G and 3G network and provides packet bearer service of the packet domain that uses PDP.

In conclusion, 
If we try to connect a web site through a proxy server in GPRS network or WCDMA, it seems to support HTTP/1.1, there is not supporting the pipelining because of a proxy server under operability with service provider.
The more this code is completed, I think, it must meet a variety changes which may be a semantic change or unexpectedly networking situations like related issue.
This issue is to avoid blocking transfer data.I have regreted that I can not show my circumstance to you.
I hope that this suggestion may be a reference for Fennec.

Comment 6

[Patrick McManus [:mcmanus]]

Albert, when I speak of hop-to-hop I refer to HTTP 'hops' as discussed in rfc 2616. These are not IP or link layer hops - indeed it correlates to a terminated TCP session between any HTTP client and HTTP server. An HTTP transaction can contain >=1 clients and >=1 servers and pipelining is defined on the connection between the client and server. If you are connected to a proxy server then the identity of the origin server is not relevant to the determination of pipelining.

I do think you have a problem with your proxy server. I'd like to find a resolution to that in bug 458994 - but the patch in this bug doesn't seem to address the right thing.

Comment 7

[Albert]

I absolutely agree with Patrick.
This issue may be restrictly involved in a proxy server.

Only what I would like to say is the more perfect mozilla's necko source.
Whichever a proxy server or a web server has some problem, I think,  mozilla should somewhat cover with it, unless this solution influences a lot performance.

You're right, "bug 458994" you said is related to this issue.

Comment 8

[Patrick McManus [:mcmanus]]

closing based on consensus of comment 3