Posts Tagged ‘Regular expressions’

What is URL Rewriting? Why Rewrite URLs?

What is URL Rewriting?

URL Rewriting is a server-side technique for mapping URL requests to request handlers.

Typically there is a direct mapping between request URL and the handler for that request. All requests that end in .php will be handled by a PHP script with the given name. Similarly, request paths that end in .html will typically be handled by a static file handler. The mapping between URL and handler is typically static, and depends solely on the extension of the URL Request.

URL Rewriting allows administrators to more flexibly map between the incoming requests and the actual resource that handles the request on the server. For example, using URL Rewriting, requests that have a .html extension could be served by ASP.NET, or requests that have no extension could be served by a PHP script.

Most URL Rewriters match the incoming URL against a set of patterns, and rewrite the URL according to which patterns match. The language used in the most powerful and flexible rewriters to describe the patterns is known as Regular Expressions. Some rewriters also allow rewriting based on other factors, including the request headers, Server variables, and even the state of the server filesystem.

Many URL Rewriters can also redirect requests. This has led to confusion in the terms Rewrite and Redirect. To learn the difference, see Redirecting versus Rewriting. IIRF can perform URL redirects as well as URL rewrites.

Why Rewrite URLs?

There are many of reasons to rewrite URLs:

1. Search Engine Optimization (SEO)
SEO is a broad topic, but the main goal is to assist search engines in finding content on a web site. One aspect of that is optimizing the URLs themselves.

2. Making user-friendly URLs.
Similar in effect to SEO, this allows the use of friendly public URLs where they are observed by users in links and browser bars. Elements within URLs that are meaningful only to server-side technology, including the extension of the server-side script or web app platform, can be obscured from the public.

3. Faking people out.
In some cases the web administrator would like to conceal the server-side technology that is being used. URL Rewriting allows, for example, a public URL that ends in .jsp to be handled by a .php script.

4. Routing requests.
You can force certain requests to use a secure connection (https), or a particular server.

5. Server-side technology migrations.
When migrating from one technology to another in stages, URL rewriting can be used to keep the URL space stable while things change on the server back-end. URL Rewriting can also be used to support migration of “old” or stale URLs to the new URL namespace, when those changes occur.

6. Injecting custom processing.
In some cases, a server administrator may wish to inject new, additional, server-side processing for well-known existing URLs. One example here is inserting special image handling logic behind a .jpg URL. You may wish to block access to image URLs from outside referrers, to limit bandwidth leaching.

7. Filtering URL requests.
An administrator may want to restrict access to certain URLs based on the referer, the requesting IP address, and so on.
You can imagine lots of other reasons, too.

IIRF lets you do any of these things.

From IIRF an ISAPI Filter solutions fro IIS

Bookmark and Share
Date: December 1, 2009
Comments: No Comments
Filed under Resources
Tags: , , , , , ,

asp.net c# – Common Regular Expressions

Copied from http://msdn.microsoft.com/en-us/library/ms998267.aspx

Field Expression Format Samples Description
Name ^[a-zA-Z''-'\s]{1,40}$ John Doe
O’Dell		 Validates a name. Allows up to 40 uppercase and lowercase characters and a few special characters that are common to some names. You can modify this list.
Social Security Number ^\d{3}-\d{2}-\d{4}$ 111-11-1111 Validates the format, type, and length of the supplied input field. The input must consist of 3 numeric characters followed by a dash, then 2 numeric characters followed by a dash, and then 4 numeric characters.
Phone Number ^[01]?[- .]?(\([2-9]\d{2}\)|[2-9]\d{2})[- .]?\d{3}[- .]?\d{4}$ (425) 555-0123
425-555-0123
425 555 0123
1-425-555-0123		 Validates a U.S. phone number. It must consist of 3 numeric characters, optionally enclosed in parentheses, followed by a set of 3 numeric characters and then a set of 4 numeric characters.
E-mail ^([0-9a-zA-Z]([-\.\w]*[0-9a-zA-Z])*@([0-9a-zA-Z][-\w]*[0-9a-zA-Z]\.)+[a-zA-Z]{2,9})$ someone@example.com Validates an e-mail address.
URL ^(ht|f)tp(s?)\:\/\/[0-9a-zA-Z]([-.\w]*[0-9a-zA-Z])*(:(0-9)*)*(\/?)([a-zA-Z0-9\-\.\?\,\'\/\\\+&%\$#_]*)?$ http://www.microsoft.com Validates a URL
ZIP Code ^(\d{5}-\d{4}|\d{5}|\d{9})$|^([a-zA-Z]\d[a-zA-Z] \d[a-zA-Z]\d)$ 12345 Validates a U.S. ZIP Code. The code must consist of 5 or 9 numeric characters.
Password (?!^[0-9]*$)(?!^[a-zA-Z]*$)^([a-zA-Z0-9]{8,10})$   Validates a strong password. It must be between 8 and 10 characters, contain at least one digit and one alphabetic character, and must not contain special characters.
Non- negative integer ^\d+$ 0
986		 Validates that the field contains an integer greater than zero.
Currency (non- negative) ^\d+(\.\d\d)?$ 1.00 Validates a positive currency amount. If there is a decimal point, it requires 2 numeric characters after the decimal point. For example, 3.00 is valid but 3.1 is not.
Currency (positive or negative) ^(-)?\d+(\.\d\d)?$ 1.20 Validates for a positive or negative currency amount. If there is a decimal point, it requires 2 numeric characters after the decimal point.
Bookmark and Share
Date: September 30, 2009
Comments: No Comments
Filed under Asp.net, C#
Tags: , , , , , , , , , ,