243811 - Changes made to http 'host' header in by http-on-modify-request not reflected by browser behaviour

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, defect)

Description

[Simon Detheridge]

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7rc1) Gecko/20040517

If I write a browser component that modifies the http "host" header when it 
responds to "http-on-modify-request", the browser still connects to the 
original host, rather than the updated one. 
 
This causes inconsistent behaviour if the user connects through a proxy server 
(transparent or otherwise) as the proxy gets the http request and connects to 
the host specified by the 'host' header, whereas if the connection is _not_ 
proxied, Moz connects to the original host. 

Reproducible: Always
Steps to Reproduce:
1. Install a component that modifies the http 'host' header to 
http://www.google.com/ 
2. Browse to http://www.mozilla.org/ 
Actual Results:  
The connection is proxied, the browser loads the index page from 
http://www.google.com/ - otherwise it loads http://www.mozilla.org/	 

Expected Results:  
Loaded the index page from http://www.google.com/ 

Admittedly, there are not many immediately obvious uses for modifying the http 
'host' header, but if combined with redirecting to a site that understands 
what mozilla is doing, it's possible to build some interesting server-side 
content-filtering things quite simply.

Comment 1

[Simon Detheridge]

Attachment: An example http header modification component

This stupid component causes the http host header to get modified to
'www.symgate.com'. (Which will spew out the http headers it recieved)

Copy to components directory, and remove 'compreg.dat' to make it work

Comment 2

[Simon Detheridge]

Attachment: Patch that seems to fix the problem

This patch appears to fix the problem. It may be horribly broken, as I've never
tried to write a moz patch before.

Comment 3

[Darin Fisher]

Interesting.  I never really considered the possibility of using this callback
to redirect the HTTP channel to a different server.  That sort of thing really
deserves a different kind of hook IMO, because for example you don't know that
some other observer that runs after your observer might try to do something like
inspect the host header for some other reason.  If you have changed the host
header then you would foil that other observer (maybe in some way that you do
not like).  Hmm... I would need to think about this some more.  We could hack
this to make it work like you have done, but I'd rather see us do it right.  Hmm...

Comment 4

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

(on the patch itself, is it really the style of the file to use as much spacing
as you do in the new part?)

So... what if an observer really only wants to modify the host header, and still
connect to the original host? for example, to request data from a different vhost.

Comment 5

[Simon Detheridge]

Sorry about the spacing. Force of habit.  
  
With regards to the point about vhosts, it probably wouldn't make any  
difference, as the dns address for the new header is likely to be pointing to  
the same server, right? And if this was being used to pull a vhost from a  
server that had a missing or invalid dns entry, this still wouldn't work if  
the connection was proxied, so the problem still applies.  
  
The feature I'm trying to 'exploit' is useful for writing a web-based content  
filter that runs as transparently possible, because by using this it is  
possible to 'trick' Moz into handing over the correct cookies for the site it  
wants to connect to, even though it's actually connecting to the "proxy". 
Basically, I want to make something that works like a proxy server (but 
filters), but lives on the public internet and is possibly behind another 
proxy server. 
  
Another solution would be to be able to daisy-chain proxies from the source  
(i.e. "moz, please connect to proxy a first, and have it forward the data to  
proxy b, and then on to the destination") but you can't do that with HTTP 1.1  
  
I looked at the docs and figured that changing the host here  
(http-on-modify-request) *did* bother me as I couldn't be sure that my  
observer was running last in the chain. So, you're right it's possible that  
this might confuse any further observers listening to the same event, that do  
things based on the host header. The purpose of doing this was to ensure that  
moz generated all the headers as if it *thought* it was talking to  
www.site.com, but actually sending that data to www.othersite.com instead.  
  
Having said that, it does remain that the existing behaviour is confusing.  
Most people I know have isp's that transparently proxy their connection, so  
the thing I was mucking about with was working on most people's connections.  
It was only when I tried it on my work connection that I discovered it behaved  
differently.  
  
Hmm..  

Comment 6

[Simon Detheridge]

Attachment: Patch that fixes the problem much better

This is an updated patch, that works if the new host contains a port number.

Comment 7

[Darin Fisher]

I'm not sure that I agree that observers of 'on-modify-request' should be
permitted to change the connection used for the HTTP channel.  It would seem
that it would be better to expose an API that allows the URI of a nsIChannel to
be modified or something like that.  I'd almost rather prevent consumers from
modifying the Host header at all.

Comment 8

[Darin Fisher]

I'd prefer to make it impossible to modify the Host header via this API.  I
think that should not be allowed.  Instead, we should provide an alternate API
for overriding the effective URI of the channel.

Comment 9

[Darin Fisher]

Comment on attachment 149414 [details] [diff] [review]
Patch that fixes the problem much better

As I said before, I am not happy with this patch.

Comment 10

[Darin Fisher]

WONTFIX

please file a different bug on implementing an API to override the effective URI
of a channel.