Our team is new to Apache. We have a SharePoint 2007 app that sits on our internal server, at an address we'll call http://internal.site.com.

We are required to use Apache as a reverse proxy from the external-facing site to the internal server. the external server is at an address we'll call http://external.site.com/appname.

The issue comes with SharePoint's relative links. links in the sharepoint page might point to "/_layouts/dir/subdir/page.aspx" but when passed through to the proxy, this link shows in the page as http://external.site.com/_layouts/... (no /appname appended on). So it seems we have to do a URL re-write.

But then this is extended to other issues -- relative URLs in stylesheets, javascript, etc. that SharePoint generates (i.e. we have no control over).

SharePoint also creates some URLs along the lines of "\u002flayouts\u002fuserdisp.aspx?Force=True\u0026ID="

So far, I think the best way to address this is, for each URL (including in stylesheets, javascript, etc.):

  1. Switch the incorrectly-facing slashes.
  2. Turn any relative URLs (URLs beginning with "/" is how i'm assuming we can define this") and turn them into http://external.site.com/appname/[URL]"
  3. Use ProxyPass and ProxyPass reverse to transform the paths (which should all now be absolute and correctly formatted).

This may be right or wrong and I welcome your opinions on how to do it better.

In pursuit of that goal, so far I've got a config file that I'm certain is wrong in many ways, but I think is a start. I'd like your opinions on how to better implement my idea as well.

ProxyRequests off
<Proxy *>
 Order deny,allow
 Allow from all

ProxyPass /appname/ http://internal.site.com/
ProxyPassReverse /appname/ http://internal.site.com/

<Location /appname/>

ProxyHTMLEnable On
ProxyHTMLExtended On
ProxyHTMLLogVerbose On

#List of HTML elements to change
ProxyHTMLLinks               a                              href
ProxyHTMLLinks               area                       href
ProxyHTMLLinks               link                         href
ProxyHTMLLinks               img                         src longdesc usemap
ProxyHTMLLinks               object                   classid codebase
data usemap
ProxyHTMLLinks               q                             cite
ProxyHTMLLinks               blockquote         cite
ProxyHTMLLinks               ins                          cite
ProxyHTMLLinks               del                          cite
ProxyHTMLLinks               form                      action
ProxyHTMLLinks               input                     src usemap
ProxyHTMLLinks               head                      profile
ProxyHTMLLinks               base                      href
ProxyHTMLLinks               script                     src for

# To support scripting events (with ProxyHTMLExtended On),
# you'll need to declare them too.

ProxyHTMLEvents           onclick ondblclick onmousedown onmouseup \
                               onmouseover onmousemove onmouseout onkeypress \
                               onkeydown onkeyup onfocus onblur onload \
                               onunload onsubmit onreset onselect onchange

#Goal: Map any URL that starts with a / (i.e. a relative link) to
ProxyHTMLURLMap ^/ http://internal.site.com/


Thank you in advance for any help you can give!

All the best, Sean

2 Answers 2


The difficulty you're facing is a common one: you want to access a web application using a different URI path than the application expects. The standard Apache proxy machinery only takes care of links in the headers (e.g., Location: headers) but not in the content of the document, so links that use absolute paths like /images/foo.png no longer reach the right place (relative paths should usually work just fine).

A common solution is to use the mod_proxy_html module, which will let you perform substitutions in the content of your web pages. In fact, this tutorial covers exactly the situation you've described.

  • Hi larsks, thanks for the answer! I'm surprised at the need to rewrite every single URL. I think that instead of doing this per type of relative URL (since SharePoint generates some of its own), the it would be better to rewrite all relative URLs to be absolute (using apache), and then using those through the reverse proxy. Does this seem correct? Feb 16, 2011 at 15:59
  • I'm not sure what you're asking, exactly. Relative URLs should Just Work (because you're not changing the relative location of pages, just the base path). Absolute URLs will break without some sort of rewriting. You can either rewrite the content of the documents, or you can use a set of RewriteRules in your Apache configuration to make the "broken" URLs work. You could simply rewrite everything that does not start with /efg/, assuming you're not hosting any other content on this host.
    – larsks
    Feb 16, 2011 at 16:08
  • The issue is that we're using apache for the reverse proxy, so outside users are hitting external.site.com/app, but it forwards internally to inside.side.com. This means that (for example with images), they are in the code as "/_layouts/" directory, which bubbles up as inside.site.com/_layouts/image which then gets translated to external.site.com/_layouts/image which is incorrect and breaks. The issue is more how to convert them properly to get the reverse proxy to work with our app as-is. Feb 16, 2011 at 16:19
  • Right. And you can use RewiteRule to make external.site.com/_layouts/ go to the right place, or you can use mod_proxy_html to rewrite the content of documents so that the links get transformed into /efg/_layouts/image.
    – larsks
    Feb 16, 2011 at 16:26
  • The issue is the reverse. Sharepoint expects to be the root, and apache is referencing it via external.site.com/app/, so sharepoint sends the values back as /_layout/, etc. and apache thinks it's external.site.com/_layout instead of external.site.com/app/_layout. Could you provide some assistance in the correct way to use RewriteRule and Mod_proxy_html to accomplish this? (Thank you so much by the way!) Feb 16, 2011 at 17:17

Why not do it using a sub domain rather than a folder:

https://efg.site.com rather than https://www.site.com/efg. You can always setup a redirect from the folder if it has to start there. This should avoid the relative links issue.

  • Thank you for the response! We would normally have chosen this path; however, this rule is mandated by the client; we don't have control over it. It's a policy for a large client, and it's just not an option to change this. So, since we're stuck, do you know any way we might be able to make it work? Feb 16, 2011 at 1:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.