I have a RESTful API which accepts all of the standard verbs, including PUT and DELETE, however most web browsers don't support PUT and DELETE in their native FORMs.
Is it possible to use my existing .htaccess to rewrite a GET request with a specific variable (&METHOD=PUT) to use the PUT verb so that my code is not required to work around this limitation in the browser?
No it is not possible to do that using rewrite as rewrite engines are for rewriting URLs while to convert request types(GET to POST for example) one needs to change message header/body.
Related
I am new in dispatcher in AEM. I am not able to understand the mod_rewite and mod_substitute in the dispatcher rewrite rule.
When does mod_rewite comes into the picture and when mod_substitute.
Both modules are used for different purposes. The documentation states:
mod_substitute
Perform search and replace operations on response bodies
That means:
Works with the outgoing response
With mod_substitute you can change what is send back to the browser. You can for example change the HTML (to a certain degree).
mod_rewrite
Provides a rule-based rewriting engine to rewrite requested URLs on the fly
That means:
Works with the incoming request
Allows you to change where an incoming request is send to.
From personal experience I would say that 99,9% you are going to work with mod_rewrite in AEM projects.
Links
Documentation mod_substitute
Documentation mod_rewrite
So I've been going through my forms recently to check my SQL queries are secure along with sanitizing any input and have just found that entering <? into a text box triggers a 403 before it even hits the processing file, I can only assume it must be related to mod_security??
My question is, is this something to just not worry about if it's controlled by the web host as I'm using shared hosting.
I recently ran into a problem with submitting form data via a GET request to the server after using jQuery's .serialize() function for the submitted variables. These were web apps that had worked flawlessly for years. It turned out that after a recent ModSecurity rule set update, I was triggering the 211700 (HTTP redirect) and 217280 (smuggling attack) rules in Comodo's WAF ruleset, which the server uses with ModSecurity. I wasn't getting a 403. My IP address got blocked by the firewall. :(
The fix was switching my AJAX code to use to POST instead of GET, and not using .serialize(). I still have some web apps that use .serialize() and GET requests via AJAX without triggering ModSecurity, so I believe it is also necessary to pass suspect characters, as you discovered, though in my testing, all I was using was parentheses.
Since you're on a shared server, it's probably not possible--or worth your time--to find out what rule set the host is using, so your best bet is most likely to switch your form submissions to using POST instead of GET, and not use .serialize(). I figure those rules are there for a reason, and a better approach is to avoid having my code look like it's doing something nefarious than to disable the rules.
I've been looking at backends and APIs for a while now. It seems that sometimes devs will build a regular backend (in say a language like PHP) that handles all the backend matters and sometimes devs will instead choose to build out their backend through an API and then use their own (and possibly other) sites to pull data from this API.
I was wondering this:
Say I want to build a regular backend using a server-scripting language like PHP, which I will use to not only render my main website, but will also allow me to do other server-side scripting etc. Then say I want to use this data from the current site and make it accessible to another site of mine through API calls. Will it be possible to build an API on top of a regular backend?
If the answer yes, how complex can it get to achieve something like this?
What tools or design strategies (if any) would you have or have used for achieving this?
This is an old question, but since I'm here, I may as well provide an answer for anyone wondering. Joe is asking about server-side web APIs versus regular server-side code.
Yes, you can have a "regular" backend and an API backend exist at the same time. If your backend is in PHP, you can refactor and extend your code to handle API requests.
Like Patrick Evans said, an API is the backend. If your backend PHP code communicates with a database to manipulate or retrieve data, then you can consider this an API transaction. Whenever your backend receives a request, evaluates/actions that request, and returns a response, it is essentially acting like an API.
Let's say you own example.com, with an index.php file in the root directory - so when a user requests example.com in their browser, this index.php file is processed and served to them. Now, you can set up this index.php file to handle both regular page requests (i.e. the php script returns an html template that is rendered by the browser) and API calls. This can be as complex or as simple as you want it to be.
The best way to handle this would be to assign different routes for rendering your main webpages and API calls. You can set up routes in the following way...
example.com/index.php?route=api&data=users can be handled by your 'API code' in index.php to return a JSON response containing a list of all the users in your database, while example.com/index.php?route=home will just return your website's home page.
We have Apache on top of JBoss serving either web or mobile app.
We are currently using Apache mod-rewrite to decide where to forward the user to web or mobile (and mod-jk to mount to JBoss), based on regular expressions matching of user-agent, but that is imprecise and error prone.
We want to use a servlet or jsp on JBoss as part of deciding whether to serve the web or mobile app (the servlet checks the user-agent in WURFL to see if this is a mobile device or a web browser).
How can I make a rewrite-condition dependent on the result of a servlet/jsp ?
(I already thought about redirecting the jsp back to two possible URLs and continue the rewrite-rule logic from there, but this gets complicated with passing URL parameters back and forth)
One conceptually simple way is to use a program-type rewritemap to call your EE-based service to check a U-A, assuming the program couldn't just perform the check itself (if you've only got some canned java interface into that DB)
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