hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Virtual Host problems
Date Tue, 17 Jan 2006 12:47:19 GMT
DEEPAK SHETTY wrote:
> Hi
> Thanks.
> 
> The default java implementation thinks differently to httpclient as any
> value of Host can be set including any port value we choose(e.g. you can
> set any value you want using jmeter).

More options do not always make a better system, especially senseless ones

Oleg

> 
> Im not sure what is correct according to the http spec though
> Thanks for the advice
> Regards
> deepak
> 
> 
>>-----Original Message-----
>>From: Oleg Kalnichevski [mailto:olegk@apache.org]
>>Sent: Tuesday, January 17, 2006 5:22 PM
>>To: HttpClient User Discussion
>>Subject: Re: Virtual Host problems
>>
>>DEEPAK SHETTY wrote:
>>
>>>Hi
>>>I realize there is no such thing as a virtual port.
>>>However let me explain.
>>>
>>>There was a MS Proxy system accessed as
>>>
>>>http://externaldns:port1/App1 which would proxy requests to
>>>http://internalip:port2/App1 (A Reverse Proxy like you point out)
>>>The MS Proxy system would add a Host Header as externaldns:port1 and
> 
> the
> 
>>>internal system depended on this host header for reasons best know to
>>>it.
>>>
>>
>>So, you are talking about a *reverse* proxy, aren't you?
>>
>>
>>>Note that port1 != port2 (and there is no reason why it should be)
>>>
>>>Now this MS proxy is being replaced by a java servlet using
> 
> HttpClient
> 
>>>And we are only able to add the host header as externaldns:port2
> 
> using
> 
>>>http client.
>>>
>>>I can't see how the spec can allow the host header ip/dns to be
> 
> changed
> 
>>>but not the port, because this solution always needs the ports to be
>>>same.
>>
>>There is no need to virtualize ports unlike the host names due to the
>>way host names get resolved to an IP address. A process is either
>>listens on a port or it does not. If you are able to show a single
>>reference to a definition of a 'virtual' port in the HTTP spec I will
>>happily change my mind
>>
>>
>>
>>>If you consider bridging reverse proxies where the external DMZ
> 
> reverse
> 
>>>proxy is accessed via HTTPS(443) , but internal network access is
>>>HTTP(80) then too this fails.
>>
>>Why? You just have to adjust the HostConfiguration settings
> 
> accordingly.
> 
>>What does this have to do with 'virtual' ports?
>>
>>
>>>I assume there is no way around this with httpclient then?
>>>
>>
>>Of course, there is. Override the HttpMethodBase#addHostRequestHeader
>>method and provide whatever logic you deem appropriate
>>
>>http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/ht
> 
> tpcl
> 
>>ient/HttpMethodBase.html#1209
>>
>>It is clearly an ugly abuse of class inheritance but this is as good as
>>it gets until HttpClient 4.0
>>
>>Hope this helps
>>
>>Oleg
>>
>>
>>>Regards
>>>deepak
>>>
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Oleg Kalnichevski [mailto:olegk@apache.org]
>>>>Sent: Tuesday, January 17, 2006 4:52 PM
>>>>To: HttpClient User Discussion
>>>>Subject: Re: Virtual Host problems
>>>>
>>>>DEEPAK SHETTY wrote:
>>>>
>>>>
>>>>>Hi
>>>>>We have a proxy servlet which proxies requests to downstream servers
>>>
>>>and
>>>
>>>
>>>>>we use HttpClient to implement the proxy. We need to pass the Host
>>>
>>>and
>>>
>>>
>>>>>Port that the user had requested for as the Host header to the
>>>>>downstream system (which is not aware of the proxy) so
>>>>>Client -->ProxyServer(http-client)-->DownStream
>>>>>		192.168.0.254(80)	    --> yadayada:8081
>>>>>						Host header
>>>>>wanted(192.168.0.254:80)
>>>>>
>>>>>Now I can use VirtualHost to specify the Host name , but theres no
>>>
>>>way
>>>
>>>
>>>>>to specify the port
>>>>>
>>>
>>>
> (http://www.mail-archive.com/httpclient-user@jakarta.apache.org/msg01357
> 
>>>>>.html)
>>>>>Or to use the example from the thread
>>>>>
>>>>>IP: 192.168.0.254
>>>>>
>>>>>virtual-host1: yadayada:8081
>>>>>virtual-host2: blahblah:8082
>>>>>
>>>>>In order to get a resource form the virtual-host1 do:
>>>>>bind to 192.168.0.254:8081
>>>>>GET /some/stuff HTTP/1.1
>>>>>Host: yadayada:8081
>>>>>
>>>>>In order to get a resource from the virtual-host2 do:
>>>>>bind to 192.168.0.254:8082
>>>>>GET /some/stuff HTTP/1.1
>>>>>Host: blahblah:8082
>>>>>
>>>>>However we need the proxy to listen on 192.168.0.254 port 80 (and
> 
> not
> 
>>>>>8081 or 8082)
>>>>>
>>>>>Are there any workarounds possible?
>>>>>Regards
>>>>>deepak
>>>>>
>>>>
>>>>Deepak,
>>>>There is no such thing as a virtual port.
>>>>
>>>>If the servlet you are writing indeed acts as an HTTP proxy (not to
> 
> be
> 
>>>>confused with a reverse HTTP proxy), then by the HTTP spec requests
>>>
>>>sent
>>>
>>>
>>>>by the clients to the proxy are supposed to look like that
>>>>
>>>>bind to 192.168.0.254:80
>>>>GET http://yadayada:8081/some/stuff HTTP/1.1
>>>>Host: yadayada:8081
>>>>
>>>>
>>>>bind to 192.168.0.254:80
>>>>GET http://blahblah:8082/some/stuff HTTP/1.1
>>>>Host: blahblah:8082
>>>>
>>>>HttpClient is perfectly capable of generating such requests if
>>>>configured properly. There is no need for a 'virtual' port at all
>>>>
>>>>Oleg
>>>>
>>>>
>>>>
>>>>
>>>>>*********************************************************
>>>>>Disclaimer:
>>>>>
>>>>>The contents of this E-mail (including the contents of the
>>>
>>>enclosure(s)
>>>
>>>
>>>>or attachment(s) if any) are privileged and confidential material of
>>>
>>>MBT
>>>
>>>
>>>>and should not be disclosed to, used by or copied in any manner by
>>>
>>>anyone
>>>
>>>
>>>>other than the intended addressee(s).   In case you are not the
> 
> desired
> 
>>>>addressee, you should delete this message and/or re-direct it to the
>>>>sender.  The views expressed in this E-mail message (including the
>>>>enclosure(s) or attachment(s) if any) are those of the individual
>>>
>>>sender,
>>>
>>>
>>>>except where the sender expressly, and with authority, states them to
>>>
>>>be
>>>
>>>
>>>>the views of MBT.
>>>>
>>>>
>>>>>This e-mail message including attachment/(s), if any, is believed to
>>>
>>>be
>>>
>>>
>>>>free of any virus.  However, it is the responsibility of the
> 
> recipient
> 
>>>to
>>>
>>>
>>>>ensure that it is virus free and MBT is not responsible for any loss
> 
> or
> 
>>>>damage arising in any way from its use
>>>>
>>>>
>>>>>********************************************************
>>>>>
>>>>>--------------------------------------------------------------------
> 
> -
> 
>>>>>To unsubscribe, e-mail:
>>>
>>>httpclient-user-unsubscribe@jakarta.apache.org
>>>
>>>
>>>>>For additional commands, e-mail:
>>>
>>>httpclient-user-help@jakarta.apache.org
>>>
>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail:
> 
> httpclient-user-unsubscribe@jakarta.apache.org
> 
>>>>For additional commands, e-mail:
>>>
>>>httpclient-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>*********************************************************
>>>Disclaimer:
>>>
>>>The contents of this E-mail (including the contents of the
> 
> enclosure(s)
> 
>>or attachment(s) if any) are privileged and confidential material of
> 
> MBT
> 
>>and should not be disclosed to, used by or copied in any manner by
> 
> anyone
> 
>>other than the intended addressee(s).   In case you are not the desired
>>addressee, you should delete this message and/or re-direct it to the
>>sender.  The views expressed in this E-mail message (including the
>>enclosure(s) or attachment(s) if any) are those of the individual
> 
> sender,
> 
>>except where the sender expressly, and with authority, states them to
> 
> be
> 
>>the views of MBT.
>>
>>>This e-mail message including attachment/(s), if any, is believed to
> 
> be
> 
>>free of any virus.  However, it is the responsibility of the recipient
> 
> to
> 
>>ensure that it is virus free and MBT is not responsible for any loss or
>>damage arising in any way from its use
>>
>>>
>>>********************************************************
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail:
> 
> httpclient-user-unsubscribe@jakarta.apache.org
> 
>>>For additional commands, e-mail:
> 
> httpclient-user-help@jakarta.apache.org
> 
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail:
> 
> httpclient-user-help@jakarta.apache.org
> 
> 
> 
> *********************************************************
> Disclaimer:   
> 
> The contents of this E-mail (including the contents of the enclosure(s) or attachment(s)
if any) are privileged and confidential material of MBT and should not be disclosed to, used
by or copied in any manner by anyone other than the intended addressee(s).   In case you are
not the desired addressee, you should delete this message and/or re-direct it to the sender.
 The views expressed in this E-mail message (including the enclosure(s) or attachment(s) if
any) are those of the individual sender, except where the sender expressly, and with authority,
states them to be the views of MBT.
> 
> This e-mail message including attachment/(s), if any, is believed to be free of any virus.
 However, it is the responsibility of the recipient to ensure that it is virus free and MBT
is not responsible for any loss or damage arising in any way from its use
>      
> 
> ********************************************************
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


Mime
View raw message