We all understand the lines in the sand (or the architectural diagram) that separate client-side scripting from server-side scripting. It's very clear that client-side scripting, e.g. JavaScript, VBScript, ActionScript, executes on the client while server-side scripting, e.g. PHP, ASP, executes on the server. But what about network-side scripting?

"There is no such thing!" might be the first response to this question, but I beg to disagree. Programmable proxies, a la F5's BIG-IP Local Traffic Manager, that provide a scripting language such as iRules, are simultaneously client-side and server-side, with the best definition to describe their placement in architectures being network-side scripting.

That's because the scripting, which is not different at all from client or server side scripting, executes in the network rather than on the client or the server. It has a view of both the client and the server and the data being exchanged between them because of its unique placement in the communication channel.

Network-side scripting essentially gives you a view of both client and server environments simultaneously, and in a single, unified location.

For example, network-side scripting can react to server-focused data like HTTP responses, cookies, and session information while simultaneously taking into consideration client-side information - HTTP requests, cookies, submitted data, and even the network conditions currently being experienced by that specific client. Because a programmable proxy is by necessity a full proxy, it is both client (to your application) and server (to the browser/customer) and can view all interactions between the two as a cohesive unit rather than as disconnected pieces of data.

[Edited to include an example, thanks to a suggestion from Bob in the comments!]

Here's an example of Cookie encryption that uses network-side scripting. The entire script runs in the network (on the proxy) but we've split the code into "client" and "server" side to show how network-side scripting can deal with both sides of the equation. There is additional script that executes when the rule is first initialized. You can check it out in the article that is the source for this code.

when HTTP_REQUEST {
   # If the error cookie exists with any value, for any requested object, try to decrypt it
   if {[string length [HTTP::cookie value $::cookie]]}{

      if {$::cookie_encryption_debug}{log local0. \
         "Original error cookie value: [HTTP::cookie value $::cookie]"}

      # URI decode the value (catching any errors that occur when trying to 
      # decode the cookie value and save the output to cookie_uri_decoded)
      if {not ([catch {URI::decode [HTTP::cookie value $::cookie]} cookie_uri_decoded])}{

         # Log that the cookie was URI decoded
         if {$::cookie_encryption_debug}{log local0. "\$cookie_uri_decoded was set successfully"}

         # Decrypt the value
         if {not ([catch {AES::decrypt $::aes_key $cookie_uri_decoded} cookie_decrypted])}{

            # Log the decrypted cookie value
            if {$::cookie_encryption_debug}{log local0. "\$cookie_decrypted: $cookie_decrypted"}
         } else {

            # URI decoded value couldn't be decrypted.
         }
      } else {
         # Cookie value couldn't be URI decoded
      }
   } else {
      # Cookie wasn't present in the request

   # Check if response contains an error cookie with a value
   if {[string length [HTTP::cookie value $::cookie]] > 0}{

      # Log the original error cookie value from the app
      if {$::cookie_encryption_debug}{log local0. \
         "Response from app contained our cookie: [HTTP::cookie value $::cookie]"}

      # Encrypt the cookie value so the client can't change the value
      HTTP::cookie value $::error_cookie [URI::encode [AES::encrypt $::aes_key [HTTP::cookie value $::cookie]]]

      # Log the encoded and encrypted error cookie value
      if {$::cookie_encryption_debug}{log local0. \
        "Encrypted error cookie to: [URI::encode [AES::encrypt $::aes_key [HTTP::cookie value $::cookie]]]"}
   }
}

The "client" side deals with client-specific events, like HTTP_REQUEST, and executes code to find and decrypt the appropriate cookie before sending the request and the now plain-text cookie to the web server.

The "server" side deals with server-side specific events, like HTTP_RESPONSE, and executes code to find and encrypt the cookie before returning the response and the now protected cookie to the client.

Network-side scripting executes in the network, on a programmable proxy such as an application delivery platform. It can store information about client-side activity and environments that can be taken into consideration when processing server responses. It can inspect and modify both client and server side data for myriad purposes including optimization, security, and to assist with implementing application-specific logic.

Network-side scripting allows you to implement application functionality in the network that can provide benefits like improved application performance; it can enable agility in both your network and application infrastructure; it can provide centralization of functionality in a service-oriented manner through reusable network-side scripts that can be applied as necessary to one, two, or all applications with minimal effort.

Network-side scripting is a powerful mechanism through which you can architect more scalable, secure, and peformant infrastructures capable of handling high-volumes of requests while protecting server-side infrastructures from the sometimes adverse affects of sudden spikes in user concurrency.