I may have it fixed but to do it I had to ignore the handle setup instructions and use port 443 instead of port 8000. That forces a secure reference. Nothing appears to happen when I click on the URI. Since http://hdl.handle.net/11122/<RefNum> points right back to the same page containing the link that makes perfect sense.
On Wednesday, October 25, 2017 at 1:11:49 PM UTC-8, wlruth...@alaska.edu wrote: > > > > On Wednesday, October 25, 2017 at 8:56:57 AM UTC-8, Mark H. Wood wrote: >> >> On Tuesday, October 24, 2017 at 9:46:58 PM UTC-4, wlruth...@alaska.edu >> wrote: >>> >>> We are using port 443 for secure connections and securing the site by >>> rewriting >>> port 80 to also go to port 443. The handle server uses ports 2641 and >>> 8000 and >>> needs them to to be non-SSL. But something is converting our >>> http://hdl.handle.net/ >>> URI links to https. So, rather than linking to the document page, we get >>> something >>> like this: >>> >>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> >>> <html><head> >>> <title>400 Bad Request</title> >>> </head><body> >>> <h1>Bad Request</h1> >>> <p>Your browser sent a request that this server could not understand.<br /> >>> Reason: You're speaking plain HTTP to an SSL-enabled server port.<br /> >>> Instead use the HTTPS scheme to access this URL, please.<br /> >>> <blockquote>Hint: <a href="https://scholarworks.alaska.edu/ >>> <https://www.google.com/url?q=https%3A%2F%2Fscholarworks.alaska.edu%2F&sa=D&sntz=1&usg=AFQjCNGW11izizmM-YA6q9kuwxADB_-w_Q>"><b>https://scholarworks.alaska.edu/</b></a></blockquote></p> >>> <hr> >>> <address>Apache/2.2.15 (Red Hat) Server at scholarworks.alaska.edu Port >>> 443</address> >>> </body></html> >>> >>> >>> >> >> I tried following the URI: link at >> https://scholarworks.alaska.edu/xmlui/handle/11122/6433 using 'curl'. >> The Handle link there is 'http://hdl.handle.net/11122/6433'. >> hdl.handle.net responded with a 303 redirect to ' >> http://scholarworks.alaska.edu:443/xmlui/handle/11122/6433' which is >> wrong: it should either use 'https:' or omit the port 443. I suspect that >> you've set 'dspace.url' to 'http://scholarworks.alaska.edu:443' instead >> of 'https://scholarworks.alaska.edu:443'. The DSpace Handle resolver >> just appends the object's handle to the value of 'dspace.url' and sends >> that back to the master resolver at hdl.net. >> >> > You're right, there was a mismatch in the dspace.cfg file between http:// > and the secure port 443. Unfortunately, changing dspace.url to clean > https:// didn't fix the problem. Same error. > > >> >>> My best guess at the moment is that the virtualhost configurations are >>> also somehow catching other ports and rewriting them in the same way. >>> >>> <VirtualHost *:80> >>> # >>> ### Redirect insecure ports to secure port 443 >>> ServerAdmin uaf-libra...@alaska.edu >>> RewriteEngine On >>> RewriteCond %{HTTPS} off >>> # RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L] >>> RewriteRule (.*) https://%{HTTP_HOST}:443%{REQUEST_URI} >>> >> >> >> This probably doesn't accomplish anything, since a rewrite to the same >> host will be stripped down to the localpart. Forcing a redirect, as in the >> line above it, should evoke a new request to the proper port. Try >> appending '[R,L]' or '[R=permanent,L]'. >> >> >> >> DocumentRoot /dspace/webapps/xmlui >>> ServerName scholarworks.alaska.edu >>> ServerAlias scholarworks >>> >>> ErrorLog logs/scholarworks.alaska.edu-error_log >>> CustomLog logs/scholarworks.alaska.edu-access_log common >>> >>> ProxyPass / http://127.0.0.1:443/ retry=10 connectiontimeout=5 >>> ### ^ this tells httpd to redirect it's / to localhost port 443 >>> >>> >> >> No. This is not a redirect. HTTPD will act like a client and ask the >> target for the localpart, then send the reply back to *its* client. Above >> HTTPD is proxying through itself, which is probably not what you want. >> Here we have no proxy rules at all for port 80, only actual redirects >> telling HTTPD's client to try again on port 443. All the proxying happens >> in the port 443 virtual host. I would just take all this proxy stuff out >> of this vhost. >> >> I commented out the proxyPass lines for <virtualhost *:80> without > breaking anything. I also added the "[R,L]" per your suggestion. So far > I've noticed no difference. > > >> >> >>> #timeout=300 >>> ProxyPassReverse / http://127.0.0.1:443/ retry=10 >>> ### ^ this tells httpd that tomcat's url's should be rewritten >>> to look >>> ### like they're coming from httpd. >>> >>> ProxyPreserveHost On >>> ### ^ this tells httpd to keep the Host: information from the >>> client and >>> ### pass it on to tomcat. >>> >>> </VirtualHost> >>> >>> #<VirtualHost scholarworks.alaska.edu:443> >>> <VirtualHost *:443> >>> >>> ### ^ this creates a httpd server that listens on port 443. >>> >>> ServerAdmin uaf-libra...@alaska.edu >>> DocumentRoot /dspace/webapps/xmlui >>> ServerName scholarworks.alaska.edu >>> ServerAlias scholarworks >>> >>> ErrorLog logs/scholarworks.alaska.edu-https-error_log >>> CustomLog logs/scholarworks.alaska.edu-https-access_log >>> combinedssl >>> >>> Include conf.d/ssl.include >>> Include conf.d/ssl.include.star >>> ### ^ these point to a file which specifies where the ssl >>> certificates >>> ### live on the host. >>> >>> ProxyPass / http://127.0.0.1:8080/ retry=10 >>> connectiontimeout=5 >>> ### ^ this tells httpd to redirect it's / to localhost port 8080 >>> >>> >> >> Again, not a redirect; this causes HTTPD to send a request to whatever is >> on port 8080 (Tomcat, I presume) and forward its response back to HTTPD's >> client. This is what you need in order to actually serve user requests. >> >> >> > > Network port 8080 is closed. But our site displays a generic default page > if the following isn't configured in server.xml (with or without the proxy > definitions in vhosts.conf): > <Connector port="8080" protocol="HTTP/1.1" > connectionTimeout="20000" > redirectPort="443" /> > I did a recursive search and see that port 8080 is configured into several > modules so I might not be able to get rid of it without rebuilding Tomcat > from scratch. But I don't believe the actual network port is necessary so > I'll leave the external network port 8080 closed. > So I'm not sure what the proxyPass is doing for <virtualhost *:443>. It > seems to be redirecting to port 8080 which redirects to 443. Together it > looks circular to me but the site breaks if I remove either the Connector > redirection or the proxy redirection, or both. > > > #timeout=300 >>> >>> ProxyPassReverse / http://127.0.0.1:8080/ retry=10 >>> ### ^ this tells httpd that tomcat's url's should be rewritten >>> to look >>> ### like they're coming from httpd. >>> >>> ProxyPreserveHost On >>> ### ^ this tells httpd to keep the Host: information from the >>> client and >>> ### pass it on to tomcat. >>> >>> #SSLUseStapling on >>> ### Added due to error when starting apache. Dayne Ellanna >>> >>> </VirtualHost> >>> >>> We once were trying to do this via Tomcat rewriting 8080 to 443. But when >>> we gave up on Tomcat I disabled the unneeded ports 8080 and 8443. I also >>> changed the proxy references to 8080 in <virtualhost *:80> to 443; that >>> won't >>> work in the <virtualhost *:443> section because it would reroute to >>> itself. >>> >>> So why do I need the 443 proxy directives at all? I tried commenting out >>> the >>> entire line but that just breaks the whole site. >>> >>> Does anyone see anything glaringly wrong with this setup? >>> I believe the local handle-server process passes the request >>> to handle.net just fine. But somewhere during the return trip >>> we're redirected to port 443 and things to south. >>> >>> >> >> The local handle resolver does not pass requests to handle.net; it >> receives resolution requests from handle.net and returns corresponding >> URLs. I think that calculating the "corresponding URL" is where the >> scheme/port mismatch happens. See above. >> >> -- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
