I'm setting up a clients area so my customers can review their site during development. I want to set it up so the URL is http://clients.mydomain.com/clientname/
Is there a way in the .htaccess file to set that as the base URL? I'm using the leading / format for my URLs in the page (ie /about/ or /css/), which will is fine locally & when I deploy to production, but doesn't work in the scenario outlined above.
The proper way would be to use relative links in your HTML, it's unreliable to try to track the referer and rewrite every subsequent request to shove the /clientname/ back in as a prefix.
If you make a subdomain for each customer, and develop sites there, you don't have to change the base URL. This will prevent other htaccess rules to break also when deploying to the live server...
So use:
http://clientname.mydomain.com
Related
I am trying to access rest API for Guest User through
http://localhost/b_marketing/api/rest/products, but the page redirects to 404 page. I have checked retrive catalog products in ACL attributes RULES, REST - attributes and REST - ROLES, correctly. It also works correctly on my other project by using these all configurations.
There is one thing I need to mention here that my project works only when I use http://localhost/b_marketing/index.php , despite of setting up the htaccess rewrites and setting rewrite from admin panel. My apache rewrites are also set.
When I use http://localhost/b_marketing/api/?wsdl it works and some xml returns.
But I cannot use http://localhost/b_marketing/api/rest/products
The Response Header is always 404.
I also cannot access REST API using http://localhost/b_marketing/index.php/api/rest/products as well.
Make sure you have rewrite rule in .htaccess.
Go to magento root folder, in your case it is b_marketing
Open .htaccess file in any editor
Locate rewrite rule for api
If you don't have .htaccess file in place, you may consider to copy fron original
Magento packagem
If you run nginx:
.htaccess is not supported. Edit the nginx configuration and add the line:
location /api {
rewrite ^/api/rest /api.php?type=rest last;
}
I read that that line sometimes is already there however with the the word break instead of last. Thats wrong, change it to last.
Make sure to use -MultiViews. As the api.php and /api path have the same name (without extension), Apache might resolve api automatically to api.php and cause trouble.
I have a setup in Laravel whereby I have different sections of the site powered by one codebase. A section is defined by the first slug of the uri:
localhost.dev/section1/feature
localhost.dev/section2/another/feature
However, I also have a domain alias/proxy for these so that each section can have its own independent branding and SEO without splitting up the codebase.
section1.dev/feature (alias of localhost.dev/section1/feature)
section2.dev/another/feature (alias of localhost.dev/section2/another/feature)
However, Symfony's HTTPFoundation appears to be too smart to be fooled by this proxy, and whenever you use URL::full() or URL::current(), the domain remains localhost.dev despite your browser telling you that you're on section1.dev or section2.dev
Is there a way to configure .htaccess differently, or is there a way to make Laravel's URL::full() or URL::current() mirror what's in your address bar?
First: a domain alias is not a proxy.
Second: the app.url config option gets used by the application to generate URLs. Try making it an empty string.
I want to show a page instead of another page, without change the second page url.
I know this is possible with htaccess.
I copied that code from a cms htaccess:
RewriteRule ^event-([0-9]+)\.html$ calendar.php?action=event&eid=$1 [L,QSA]
with that code, we will redirect to calendar.php?......... but I want it redirect (without changing the address in address bar) to another site, for example to http://www.google.com/page......
Is it possible?
Thanks ..
If you want to provide content from another site without changing the address in the address bar of the browser that mean you becomes a proxy.
So check apache documention for proxy configuration (this can be done for specific urls only). Even mod_rewrite can do the proxy things with the [P] tag, mod_rewrite will allow a lot more 'specific url' filtering.
Now the job of a proxy, when he have the response from the distant website and he needs to render it for the HTTP client, is only to change the HTTP headers in the response. So only url in Location tags or such specific headers will be altered. You must known that all the HTML content from the distant website will not be altered (the inner links will be on www.google.com and not on your www.whythehelldoiproxygooglewithmysite.com).
If you want to alter this returned content check mod_proxy_html module, this will add some extra stuff before sending the resonse, to do some more reverse proxy alterations.
We have a CMS system that creates long URLs with many parameters. We would like to change the way they are presented, to make them more friendly.
Since we have many sites already built on this CMS, it's a little difficult to rewrite the CMS to create friendly urls (although it's a method we're considering, if no alternative is found), we we're looking for a method that when a user clicks on a long url, the url will change into a friendly one - in the browser - without using Response.Redirect().
In Wordpress such a method exists (I'm not sure whether it's done in code or in Apache), and I'm wondering if it could be done in ASP.NET 2.0 too.
Another thing to take into consideration is that the change between the urls has to be done by accessing the DB.
UPDATE: We're using IIS6
If you're using ii7 the easiest way to do this is to use the URL Rewrite Module According to that link you can
Define powerful rules to transform
complex URLs into simple and
consistent Web addresses
URL Rewrite allows Web administrators
to easily build powerful rules using
rewrite providers written in .NET,
regular expression pattern matching,
and wildcard mapping to examine
information in both URLs and other
HTTP headers and IIS server variables.
Rules can be written to generate URLs
that can be easier for users to
remember, simple for search engines to
index, and allow URLs to follow a
consistent and canonical host name
format. URL Rewrite further simplifies
the rule creation process with support
for content rewriting, rule templates,
rewrite maps, rule validation, and
import of existing mod_rewrite rules.
Otherwise you will have to use the techniques described by Andrew M or use Response.Redirect. In any case I'm fairly certain all of these methods result in a http 301 response. I mention this because its not clear why you don't want to do Response.Redirect. Is this a coding constraint?
Update
Since you're using IIS 6 you'll need to use another method for URL rewriting.
This Article from Scott Mitchell describes in detail how to do it.
Implementing URL Rewriting
URL rewriting can be implemented
either with ISAPI filters at the IIS
Web server level, or with either HTTP
modules or HTTP handlers at the
ASP.NET level. This article focuses on
implementing URL rewriting with
ASP.NET, so we won't be delving into
the specifics of implementing URL
rewriting with ISAPI filters. There
are, however, numerous third-party
ISAPI filters available for URL
rewriting, such as:
ISAPI Rewrite
IIS Rewrite
PageXChanger
And many others!
The article goes on to describe how to implement HTTP Modules or Handlers.
Peformance
A redirect response HTTP 301 usually only contains a small amount of data < 1K. So I would be surprised if it was noticeable.
For example the difference in the page load of these urls isn't noticible
"https://stackoverflow.com/q/4144940/119477"
"https://stackoverflow.com/questions/4144940/url-rewrite-without-redirect-in-asp-net"
(I have confirmed using ieHTTPHeaders that http 301 is what is used for the change in URL)
Page Rank
This is what google's webmaster central site has to say about 301.
If you need to change the URL of a
page as it is shown in search engine
results, we recommended that you use a
server-side 301 redirect. This is the
best way to ensure that users and
search engines are directed to the
correct page.
In response to extra comments, I think what you need to do is bite the bullet and modify the CMS to write the new links out into the pages. You've already said that you have normal URL rewriting which can translate the new URLs to old when they're incoming. If you were to also write out the new URLs in your markup then everything should simply work.
From an SEO point of view, if the pages your CMS produces have the old links, then that's what the search engines will see and index. There's nothing much you can do about that, javascript, redirect or otherwise. (although a permanent redirect would get you a little way there).
I also think that what you must have been seeing in Wordpres was probably a redirect. Without finding an example I can't be sure though. The thing to do would be to use Fiddler or another http debugger to see what happens when you follow one of these links.
For perfect SEO, once you've got the new URLs working outbound and inbound, what you'd want to do is decide that your new URLs are the definitive URLs. Make the old URLs do a redirect to the new URLs, and or use a canonical link tag back to the new URL from the old one.
I'm not certain what you're saying here, but basically a page the user is already reading contains an old, long, URL, and you'd like it to change to the new, short URL, dynamically on the client side, before the browser requests the page from the server?
The only way I think this coule be done would be to use Javascript to change the URL in response to onclick or document.ready, but it would be pointless. You'd need to know the new short url for the javascript to re-write to, and if you knew that, why not simply render that url into the link in the first place?
It sounds more like you want URL routing, as included in ASP.Net 4 and 3.5?
Standard URL rewriting modifies the incoming request object on the server, so the client browser submits the new URL, and the downstream page handlers see the old URL. I believe the routing things extend this concept to the outgoing response too, rewriting old urls in the response page into new URLs before they're sent to the client.
Scott Gu covers the subject here:
http://weblogs.asp.net/scottgu/archive/2009/10/13/url-routing-with-asp-net-4-web-forms-vs-2010-and-net-4-0-series.aspx
Scott Gu also has an older post on normal URL rewriting outlining several different ways to do it. Perhaps you could extend this concept by hooking into Application_PreSendRequestContent and manually modifying all the href values in the response stream, but I wouldn't fancy it myself.
http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx
One of YSlow's measurables is to use cookie-free domains to serve static files.
"When the browser requests a static
image and sends cookies with the
request, the server ignores the
cookies. These cookies are unnecessary
network traffic. To workaround this
problem, make sure that static
components are requested with
cookie-free requests by creating a
subdomain and hosting them there." --
Yahoo YSlow
I interpret this to mean that I could experience performance gains if I move www.example.com/images to static.example.com/images.
Although this is easy to do, I would lose the handy ability within my content management system (Joomla/WordPress) to easily reference and link to these images.
Is it possible to use .htaccess to redirect all requests for a particular folder on www.example.com to a folder on static.example.com instead? Would this method also fool the CMS into thinking the images were located in the default locations on its own domain?
Is it possible to use .htaccess to redirect all requests
for a particular folder on www.example.com to a folder on
static.example.com instead?
Possible, but counter productive — the client would have to make an HTTP request, get the redirect response, then make another HTTP request.
This costs a lot more than the single line of cookie data saved!
Would this method also fool the CMS into thinking the images
were located in the default locations on its own domain?
No.
Although this is easy to do, I would
lose the handy ability within my
content management system
(Joomla/WordPress) to easily reference
and link to these images.
What you could try to do is create a plugin in Joomla that dinamically creates these references.
For example, you have a plugin that when you enter {dinamic_path path} in an article, it appends 'static.example.com/images' to the path provided. So, everytime you need to change the server path, you just change in the plugin. For the links that are already in the database, you can try to use phpMyAdmin to change them in this structure.
It still loses the WYSIWYG hability in TinyMCE, but is an alternative.
In theory you could create a virtual domain that points directly to the images folder, such as images.example.com. Then in your CMS (hopefully at the theme layer) you could replace any paths that point to the images folder with an absolute path to the subdomain.
The redirects would cause far more network traffic, and far more latency, than simply leaving things as they are.
It would redirect the request but the client would still be sending its cookies to the server, so really you accomplished nothing. You would have to directly access the files from a domain that isn't storing cookies for it to work.
What you really want to do is use staticexample.com/images instead of static.example.com/images so that you don't pick up any cookies on the example.com domain that you may have set. If all you do is server images from that domain with a simple apache server or something then you can configure that server not to return even a session cookie.
The redirects are a very bad idea. Cookies cause some performance hits but round trips to the server such as a redirect would cause are a much more serious performance issue.
I did below and gained success:
<FilesMatch "!\.(gif|jpe?g|png)$">
php_value session.cookie_domain example.com
</FilesMatch>
What it means is that if you do not set images in cookie information.
Then images are cookie-free with server.