303208 - Make a connection refused error in mid-connection drop display of the document

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement)

Description

[Olivier Guezenec]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

On Windows, many parental control software use LSPs (layered Service Protocol),
sort of proxy between the web server and the browser. When they block a page
after content analysis, they send back a socket error like "WSAECONNREFUSED",
and then the browser MUST NOT display the page, But FF displays it without
testing the error status code. This why parental control programs have no other
choice to close FF when a page is blocked, which is an annoyance for the user.
IE has not this problem.

Reproducible: Always

Steps to Reproduce:
1. Install Windows parental control based on content analysis and LSP
2. Go to a forbidden site
3. 

Actual Results:  
The page is fully displayed.

Expected Results:  
The page must not be displayed.

Comment 1

[PikeUK]

->NSPR

Apologies if that's the wrong product.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> then the browser MUST NOT display the page

Why?  Where is this documented?

Comment 3

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

fwiw, when mozilla gets a connection refused error, it does not normally display the page... in fact, I can't think of a case where it would. this needs something resembling a testcase.

Comment 4

[Olivier Guezenec]

If the connection refused error occurs only at the last chunk, the page is partially displayed. This is what happens with parental control software. In this case, the wished behavior is a cleared window or an error page.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Connection refused is an error that makes sense when establishing the connection.  It makes absolutely no sense once a connection has already been established (there is nothing to refuse once the connection request has been accepted!).  So I'm not sure I follow comment 4....

Comment 6

[Olivier Guezenec]

So what is the socket code error to return when a parental control programs wants to cancel and clear the whole current page? It's not always at the first chunk that this decision is taken, and it's never at the connection time for content analysis.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I really can't see a good reason for a socket error code to clear what is currently displayed of a page.  We generally try to show as much information as possible to the user for the resource requested (eg. show part of an image up to the point where we can't make sense of the data anymore, show the HTML up to where we can, etc).

In any case, it seems to me like the scheme you describe would fail if the user simply stops the load before your program can send this socket error...  That is, the data you pass on before you send a socket error will be available to the user no matter what.  The only way I see of doing this sort of thing right is to buffer up all the data and scan it, then send it on to the browser.

Comment 8

[Olivier Guezenec]

The case of stopping the load is not as issue in practice.
I agree with the proxy solution, but it's far to be the more efficient one.
I agree with the fact that there is no RFC or standard speaking about the behavior between browsers and content analysis applications, but to display an error page when socket error like "connection refused" occurs seems not to be a big deal.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> The case of stopping the load is not as issue in practice.

Why not?  You're trying to stop users from getting at data, and they can just work around your stuff in a trivial way, it seems to me.

> to display an error page when socket error like "connection refused" occurs
> seems not to be a big deal.

It's a big deal as far as I can see if there is a fundamental commitment to showing the user all the usable data even in the face of errors (as there is), as long as those errors do not affect the integrity of that data.

Put another way, if you unplug the network cable while loading a web page, we should show the part of the web page that got downloaded before the net connection went down.  This case is no different, imo.

Comment 10

[Olivier Guezenec]

> Why not?  You're trying to stop users from getting 
> at data, and they can just work around your stuff 
> in a trivial way, it seems to me.

Maybe at 56K, but should be speedy with broadband connection.

> Put another way, if you unplug the network cable while 
> loading a web page, we should show the part of the web 
> page that got downloaded before the net connection went 
> down.  This case is no different, imo.

The idea is to dedicate one code error for that purpose, and "connection refused" is a good candidate. No possible conflict with other network errors. The underlying question is: does a personalized treatment according to the socket error number is acceptable or not.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> and "connection refused" is a good candidate

Not really -- that code is already defined to mean something else than "clear the page immediately".

Anyway, confirming the request, but this would have to be done outside of the networking library; not really sure where would be a good spot.

Comment 12

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

> Maybe at 56K, but should be speedy with broadband connection.

some people still use such connections, you know...

fwiw, I am opposed to clearing the current page when receiving a socket error.

Comment 13

[Patrick McManus [:mcmanus]]

we do streaming rendering as best we can.. other strategies can be used for content blockers (such as the blocker doing the buffering - or an addon).. this proposed solution overlaps with too many unrelated scenarios