Break anywhere in Javascript from Firebug

Developing client side code can be challenging, often you need to be able to break at very specific place in the code to debug an issue, check a variable value or troubleshoot a non operational point.

Firebug has a very useful feature, 'Break on Next' which can be used to break on the next line of javascript that executes.  However, most pages have mouseover effects, click events and other things that may fire before you can ever get to the thing that you want to break on.  What if you want to break on a sub menu that can only be reached by clicking on it's parent? 

Firebug 1.10a8 introdcued a short cut key to enable 'Break on Next'. This allows you to get your mouse lined up on the exact position in your app that you want to break on, hit CTRL-ALT-B on your keyboard and then click.  This allows you to get past all the mouseover, onclick and other issues and break on exactly the click you want to break on.

Using an F5 iRule to solve cross domain ajax calls instead of CORS or JSONP

As a web developer at some point you will likely face a requirement to make cross-domain calls from a client side web page.  To prevent data from being loaded from multiple sites and presented as all belonging to the same site, browsers have a form of security built in that prevents scripts from being able to load data from other sites.

I recently worked with a situation that required deployment of a new RESTful web service layer that worked in concert with an existing ASP.Net application.  A process of refactoring required the projects to be treated separately and to be deployed on different URLs.  Both URLs were owned by the same organization and browser version compatibility requirements were well defined.  The browser support requirement included IE7 and newer, Firefox, Chrome and Safari.

Due to browser support issues, it was not ideal to use either CORS or JSONP to meet the requirements as both have various issues with certain browsers.  After reviewing the F5 documentation a solution was created using an iRule on the switch to represent the RESTful web site as a 'virtual folder' under the main web site.  This hides the real location of the REST service layer from the client and the client browser is not aware of the switch happening behind the scenes.  The client sees the RESTful service site on the same URL as the ASP.net site and nothing special is needed to make ajax calls.

when HTTP_REQUEST {
  if { [HTTP::uri] starts_with "/restservice" } {
    if {([string tolower [HTTP::host]] contains "aspapp.example.com")}{
      HTTP::header replace "Host" "restsvc.example.com"
 HTTP::uri [substr [HTTP::uri] 12 ]
    }
  }
}

This iRule traps on URI's that begin with /restservice.  If found it verifies that the host is the ASP.net application URL, and replaces it with the restservice URL replacing the Host from it's original URL (restsvc.example.com). The final command modifies the URI to remove the virtual folder from the call to create the new, proper URL that can be interpreted by the server.

The iRule allows pages at: aspappdomain.example.com to make ajax calls to the rest service at aspappdomain.example.com/restservice even though that URL doesn't actually exist anywhere, except in this iRule.

The key to making this work is that both sites must be serviced on the same IP address and be using host header names to serve the proper content.  If the sites are on different IPs the iRule will have no effect.

These few lines of code saved a lot of work on the client side and ensured support accross all browsers quickly and easily.