Re: [users@httpd] Apache Reverse Proxy / Redirect Issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

By moving the <Location...> section into the <VirtualHost *:443...> section (it used to be in a global location before) I got my http requests to be redirected to https requests. So, I was able to un-comment the SSLRequireSSL direction in the <Location...>, and now the flow is working out like this: 

{1b} #request# https://gateway/vqwiki-2.7.1
{2b} #response# HTTP 302 (Location: http://gateway/vqwiki-2.7.1/someResource) 
{3b} #request# http://gateway/vqwiki-2.7.1/someResource
{4b} #response# HTTP 302 (Location: https://gateway/vqwiki-2.7.1/someResource) 
{5b} #request# https://gateway/vqwiki-2.7.1/someResource
{6b} #response# HTTP 200
This is a step closer to where I want to be, because at least now the actual data (line {6b}) is coming through SSL, not in the clear through port 80.
However, as you can see in line {2b}, the Location response header is still wrong. How can I configure Apache so that the appropriate Location header is constructed? If this is fixed, then everything else will fall into place. It just seems like I am missing something in the <Location...> section. ProxyPassReverse is supposed to take of this for me, but it's not working right. 

Thanks,
Daniel

apache-user@xxxxxxxxxxx wrote:

Owen,

Thank you so much for your help!  I really appreciate it.

The reason I set up a virtual host was so that only requests on port 80
would be re-written, or rather that the condition would only be checked in
those cases.  However, your reasoning is correct in that putting a
condition of not 443 in a port 80 VH was redundant.

I had mentioned I was getting a HTTP Response 403 - Forbidden when
requesting https://gateway/vqwiki-2.7.1 and applying the rules outside of
the virtual host, i.e.

Listen 0.0.0.0:80

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [L,R]

<Location /vqwiki-2.7.1>
      ProxyPass http://backend:4080/vqwiki-2.7.1/
      ProxyPassReverse http://backend:4080/vqwiki-2.7.1/
      SSLRequireSSL
</Location>

I figured out why last night.  It's because the
https://gateway/vqwiki-2.7.1 was redirecting to
http://gateway/vqwiki-2.7.1/someResource, and because of the
"SSLRequireSSL" directive in the /vqwiki-2.7.1 Location section, it was
returning 403 (forbidden).  Commenting out this directive actually gave me
the resource (HTTP Reponse 200).

So what is happening now is the following:

{1a} #request# https://gateway/vqwiki-2.7.1
{2a} #response# HTTP 302 (Location: http://gateway/vqwiki-2.7.1/someResource)
{3a} #request# http://gateway/vqwiki-2.7.1/someResource
{4a} #response# HTTP 200

Before, line {4a} was returning 403 (Forbidden) because of the
SSLRequireSLL directive.

OK, so now it's working, but not really, because I was expecting the
redirected request (line {3a} in the above flow) would be re-directed back
to https:

{1b} #request# https://gateway/vqwiki-2.7.1
{2b} #response# HTTP 302 (Location: http://gateway/vqwiki-2.7.1/someResource)
{3b} #request# http://gateway/vqwiki-2.7.1/someResource
{4b} #response# HTTP 302 (Location:
https://gateway/vqwiki-2.7.1/someResource)
{5b} #request# https://gateway/vqwiki-2.7.1/someResource
{6b} #response# HTTP 200

This would be satisfactory.  But of course the ideal would be that the
Location header be picked properly, e.g.:

{1c} #request# https://gateway/vqwiki-2.7.1
{2c} #response# HTTP 302 (Location:
https://gateway/vqwiki-2.7.1/someResource)
{3c} #request# https://gateway/vqwiki-2.7.1/someResource
{4c} #response# HTTP 200

I hope I am communicating clearly.  Thanks again for your help.  I hope
this thread will help others who run into a similar problem.

-Daniel



-----Original Message-----
From: Daniel Silva [mailto:apache-user@xxxxxxxxxxx]


...


Here are the mod_proxy rules I am using on the gateway server:

~~~

<Location /vqwiki-2.7.1>
    ProxyPass http://backend:4080/vqwiki-2.7.1/
    ProxyPassReverse http://backend:4080/vqwiki-2.7.1/
    SSLRequireSSL
</Location>


So this is an SSL server... OK.



~~~

Here are the mod_rewrite rules I was using in a virtual host
on port 80,
when I was trying to re-write http to https requests:

~~~

Listen 0.0.0.0:80

<VirtualHost _default_:80>


Why are you actually using "VirtualHost"? Do you have more than one
server? If so, are the VHs port-based or name-based? If name-based, the
ServerName directive should be inside.



SSLEngine Off
        Redirect / https://gateway/


So this redirects top-level requests to HTTPS. Does this work? ie, does
http://your-server/ redirect to https://gateway/ ?



        RewriteEngine on
        RewriteCond %{SERVER_PORT} !^443$


Since this condition is inside a VH bound to port 80, it must always be
true - so unnecessary. Never mind..



        RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [L,R]


This should work - what does it say in the rewrite_log?



</VirtualHost>


As a general point, you don't need Redirect and RewriteRule - you could
achieve all of the above with:

<VH>
	RedirectMatch /(.*) https://%{SERVER_NAME}/$1
</VH>

Rgds,
Owen Boyle
Disclaimer: Any disclaimer attached to this message may be ignored.




ServerName gate.platinumsolutions.com:80
UseCanonicalName Off

~~~

There are more directives, the ssl-specific ones are in a
separate conf
file.  Let me know if you need to see anything from there.

I have one more thing for you... the headers on the redirect request
(from LiveHTTPHeaders extension on Firefox).  You'll notive
in the 302
response headers that the Location header has http:// instead of
https://... this is the matter that is driving me crazy and
am trying to
solve.  Here they are:

~~~

https://gateway/vqwiki-2.7.1/jsp/test2.jsp?action=redirect

GET /vqwiki-2.7.1/jsp/test2.jsp?action=redirect HTTP/1.1
Host: gateway
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050317 Firefox/1.0.2
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9
,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://gateway/vqwiki-2.7.1/jsp/test.jsp
Cookie: username=Daniel Silva;
JSESSIONID=5A37231975613F6D24D4B2B48F7EBB6B;
JSESSIONIDSSO=7083BB840927C2DC40255E36808997E1
Authorization: Basic ZHNpbHZhOmQ0bnMxbHZh

HTTP/1.x 302 Moved Temporarily
Date: Thu, 07 Apr 2005 00:26:16 GMT
Server: Microsoft-IIS/5.0
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 19:00:00 EST
Location: http://gateway/vqwiki-2.7.1/jsp/test.jsp?action=redirect
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-US
Content-Length: 0

~~~

I hope this extra info will make things more clear.

Regards,
Daniel



--------------------------------------------------------------
----------


*From:* Boyle Owen [mailto:Owen.Boyle@xxxxxxx]
*Sent:* Wed 2005-04-06 11:51
*To:* users@xxxxxxxxxxxxxxxx
*Subject:* RE: [users@httpd] Apache Reverse Proxy / Redirect Issue

Plain text please...

Then post the relevant rewrite rules from your config (not


much can be


done/said without them).

Rgds,
Owen Boyle
Disclaimer: Any disclaimer attached to this message may be ignored.

-----Original Message-----
From: Daniel Silva [mailto:dsilva@xxxxxxxxxxxxxxxxxxxxx]
Sent: Mittwoch, 6. April 2005 16:09
To: users@xxxxxxxxxxxxxxxx
Subject: [users@httpd] Apache Reverse Proxy / Redirect Issue


Hello everybody.  I am new here, was hoping to post a problem I am
having, would love to hear some input.  I've been dealing with this
problem for a while now and it's driving me nuts, haven't


been able to


find the problem.

I have a gateway server that is running OpenBSD and Apache


2 and is set


up with mod_ssl and mod_proxy.  The only listen port is


443.  I have it


configured so that a bunch of requests are handled by a


backend server,


running on port 4080.  Something like


https://gateway/resourceA maps to


http://backendserver:4080/resourceA.  I have ProxyPass to handle
requests, and ProxyPassReverse to handle the redirects.  However,
ProxyPassReverse doesn't seem to be doing it's job, because


redirects


are not working properly.

Let me explain what I mean.  Let's say, for example, that
resourceA/test1.html redirects in the backend server to
resourceA/test2.html.  When I request
https://gateway/resourceA/test1.html, I would expect to get
https://gateway/resourceA/test2.html.  However, instead


what happens is


that the redirect generates a request on port 80, or
http://gateway/resourceA/test2.html.  This, of course,


times out because


my Apache instance on my gateway server is not listening on


port 80, nor


is my firewall allowing communication on port 80 to this


gateway server.


I tried opening up port 80 on my firewall, listening on


port 80, and


writing some mod_rewrite directives to redirect requests on


http:// to


https://.  This does not work.  The redirect generated is


still for port


80 (it is not getting re-written to https), and of course


it can't find


any such resource on the gateway server, so I get a 403


back (which is


odd, I would have expected 404, but I am getting a


forbidden HTTP code


back).

I suspect this has to do with how I am setting up the servername
directive.  Right now I have it set up as gateway:80 (I am


using the


actual domain, not the word 'gateway' but the actual domain is not
important).  If I change it to gateway:443, I get a bunch of errors
logged that say "warning: running http over an https port"


or something


like that.

I don't know if I've said enough to characterize the problem.  I've
searched the net and usenet groups up and down looking for


an answer,


but I've yet to find a solution.  Please help!!

Thanks,
Daniel

--
Daniel A. Silva
Senior Consultant, PlatinumSolutions, Inc.
PH: 703.471.9793 FAX: 703.471.7140

daniel.silva@xxxxxxxxxxxxxxxxxxxxx

http://www.platinumsolutions.com

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information.


If you have


received it in error, please notify the sender immediately


and delete


the original. Any other use of the email by you is prohibited.

Diese E-mail ist eine private und persnliche Kommunikation. Sie hat
keinen Bezug zur B rsen- bzw. Geschftst tigkeit der SWX


Gruppe. This


e-mail is of a private and personal nature. It is not


related to the


exchange or business activities of the SWX Group. Le prsent


e-mail est


un message priv  et personnel, sans rapport avec l'activit


boursi re du


Groupe SWX.


This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any


mistransmission.


If you receive this message in error, please notify the


sender urgently


and then immediately delete the message and any copies of


it from your


system. Please also immediately destroy any hardcopies of


the message.


You must not, directly or indirectly, use, disclose,


distribute, print,


or copy any part of this message if you are not the


intended recipient.


The sender’s company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where


the message


states otherwise and the sender is authorised to state them


to be the


views of the sender’s company.




---------------------------------------------------------------------


The official User-To-User support forum of the Apache HTTP


Server Project.


See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx




---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP
Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx





This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please notify the sender urgently and
then immediately delete the message and any copies of it from your system.
Please also immediately destroy any hardcopies of the message. You must
not, directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient. The sender’s
company reserves the right to monitor all e-mail communications through
their networks. Any views expressed in this message are those of the
individual sender, except where the message states otherwise and the
sender is authorised to state them to be the views of the sender’s
company.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx






---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx




---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux