Creating Splash Pages

7/29/2019 Creating Splash Pages

1/15

SGOS 3, 4 Series

Creating Splash Pages

What are Splash Pages?

Many organizations would like to send out notices to their employees, ensure that the employees see the

corporate Internet Use policy, or direct the employees' rst Web request to the corporate intranet Web site.

A splash page is the page to which the employees would be redirected. This document describes how splash

pages can be implemented on the ProxySG appliance.

Behavior Summary

For the implementation described in this TechBrie:

Userswillseeonesplashpageperintervalasdefnedbytheadministrator

Isupportedbytheuseragent,thesplashpagewillbereplacedbytherequestedcontent

System Requirements

This TechBrie describes how splash pages can be implemented using eatures introduced in the ProxySG. It

makes use o specic eatures not available in previous versions, including:

Additionalsubstitutions(explainedlater)

This implementation uses redirection to a virtual "splash" domain. The secure proxy appliance must receive

requests destined or this domain.

Limitations

SplashpagescanonlybedeliveredtoclientsrequestingHTMLcontentovertheHTTP(orterminatedHTTPS)protocol. In the implementation described in this note, requests made through other protocols or or other

types o content will be unaected.

Mechanisms to control the presentation o the Splash page are not secure, and rely on plain text cookies. The

user agent must thereore be congured to accept cookies. Setting short absolute expiry times is susceptible to

clock drit problems that may result in continual splashing.

For the ProxySG, the splash domain must be DNS resolvable.

Overview

Splash pages are implemented by:

1 Defning a custom exception page. The exception uses HTML to dene a splash exception page that

will be displayed to users. On this page you can place a description o the corporate Web access policy,

provide notication messages or users, or other appropriate inormation. The splash exception page

should also contain a mechanism to obtain the originally requested content.

2 Defning policy to determine whether or not the client has already been splashed and to display the

splash exception page as appropriate.

Technical Brie: Creating Splash Pages


2/15

Dening the Splash Exception

The Splash exception page is dened using the exception eature introduced in the ProxySG. You should dene

your exception page using your avorite HTML source editor, ater reading through the sample source and the

rest o this technical brie. Briefy, exceptions have a hierarchical structure. We dene an exception by dening

a name, and various other values that distinguish our exception rom the rest. In particular, we should be aware

o the ollowing exception eatures:

ID This is the name we will use to reerence the exception in policy.

In our example, we will dene this to be "splash". The ully qualied name o the exception

will be "user_dened.splash".

Format This is the ormat used by non-HTTP protocols when they return the exception.

Since we cannot use splash pages or non-HTTP protocols, we do not dene or use thisormat or the splash exception.

HTTP Format This is the ormat used by the HTTP protocol when it returns exceptions. This ormat is

usually dened using HTML, and may contain CPL substitutions

Contact Thisisthevalueo$(exception.contact),thestandardexceptionpagesubstitutionorhelpdesk contact inormation.

HTTP Format

Here is an example o a corporate splash page. The HTML source we will use to dene the HTTP ormat or a

splash exception page is shown on the next page:



3/15

Sample Splash Exception Page

IMPORTANT NOTICE

System maintenance is scheduled for Sunday July 17, 2:00-

4:00 am EST.

To report any conicts with the scheduled maintenance,

$(exception.contact)

Click here to continue.

INTERNET USAGE IS ROUTINELY MONITORED AND

LOGGED.

Your

IP address: $(client_address)

Your username: $(user.name)

Important Notes

1 The amount o time beore the splash page is rereshed with the original content is determined by the

frstvaluesuppliedtotheRereshtag'scontent=option(line6),andissetto10orthisexample.

2 CPL(ContentPolicyLanguage)substitutionsareusedinthesamplesplashpagetoreporttheuser'sname and IP address, and to include the URL or the original content. You may want to use other CPL

substitutions in your splash page. See other Blue Coat documentation or urther inormation about the

list o CPL substitutions available.

3 Thesplashpageuses$(server_url)oraccesstotheoriginalcontentbecausearewriteactionmustbeusedto recover the original URL when serving the splash page. The Policy section explains urther details.

4 Thissamplepageuses$(exception.contact)toincludealinktoemailtheservicedesk.Youwillneedtocustomize this link to provide the correct contact inormation i you choose to include such a eature in

your own splash page.

5 Thisexceptiondefnitionreerences$(user.name),whichimpliesthatweexpectanauthenticate()property to be applied somewhere in the policy. I policy does not cause an authentication to occur

beore the exception is set, then remove this reerence rom the exception ormat.



4/15

6 This sample page states "Internet usage is routinely monitored and logged". That is assumed true as

part o the standard corporate practice specied elsewhere in the policy rules, and merely refects

the type o text likely to appear in practice. Setting the splash exception has no side eect on logging

behavior. See the Variations section or an example o how to couple logging policy to the splash page.

7 This sample splash page includes an explicit link that users can use to etch the original content i

automatic reresh is not supported by the user agent.

Loading the Exception

TheexceptiondefnitioncanbeloadedthroughtheBlueCoatCommandLineInterace(CLI),eitherasaninlinedenition or through an installable list. For example, to create an exception named "splash" as described above

using an inline denition in the CLI, you would enter the ollowing commands once in enable mode:

SG3000#cong t

SG3000#(cong)exceptions

SG3000#(cong exceptions)create splash

ok

SG3000#(cong exceptions)edit splash

SG3000#(cong exceptions user-dened splash)inline http

format xxxeof

xxxeof

SG3000#(cong exceptions user-dened coach)exit

Testing

To test the exception page use the ollowing steps:

1 Log in to the Blue Coat Management Console

2 Select Statistics -> Advanced

3 Click on the "Exceptions" link.

4 Click on the "View Exceptions Conguration" link

Under the heading User-Defned Exceptions, you should see an entry or the splash exception.

Clickingonthe"ViewSettings"linkwilldisplaytheexceptionsettingsasenteredattheCLI(commandlineinterace).

Clickingonthe"ViewSampleHTML"linkwillshowasampleotheexceptionpage,withsomesampledata values used or any dened substitutions.

Policy

The next step is to dene a Blue Coat policy to control the presentation o the splash page.

Here is the theory o operation:

1 An articial "splash domain" is used to keep track o the splashed state using cookies.



5/15

2 When a request arrives, a policy determines i the client has already been splashed by looking or a

splash cookie. When the client browses to a new domain, the splashed cookie will not be present in

the request. In this case the splash cookie is set or the new domain and the client is redirected to the

splash domain with a URL in which the original URL is encoded.

3 In the request to the splash domain, the presence o a splash cookie in the request indicates that the

client has already been splashed. I the client has been splashed, the original URL is recovered rom

the request URL and the client is redirected back to the original location. I the splashed cookie is not

presented in the request to the splash domain, the client has not been splashed, so the splashed cookie

is set and the splash exception page is returned. The splash exception page has a mechanism to obtain

the originally requested content.

4 When the client once again requests the original content, the request is accompanied by the splash

cookieandisallowedthrough(subjecttootherpolicy).

A suitable set o conditions or determining when to return the splash page ollows. The rst condition is usedto ensure the client is expecting HTML content, which is a requirement or delivering the splash page. As well,

we ensure that the Web request is not destined or the address o the management console by adding console_

access=no to the condition.

; We can only splash when the user is expecting HTML content,

; and we will not splash explicitly proxied administrators.

;

dene condition can_splash

console_access=no response.header.Content-Type="text/html"

end

The next condition tests or the presence o the splash cookie, which indicates that the user has already seen

the splash page.

; true if we nd the splash cookie

;

dene condition splash_cookie_is_present

request.header.Cookie="splashed=yes"

end

Note: This example uses "splashed=yes" or clarity. You may want to use a more obscure cookie description inreal deployments.

I a request is not or the splash domain and the splash cookie is present, we let that request through.

Otherwise, i we can splash, the ollowing action is invoked:

; For each new domain visited, the user is redirected to; the splash domain, to see if they've already been splashed.

;

dene action check_for_splash

; Preserve the original URL as part of the redirection, so

; we can do the check and use the original URL to then get the

; content.

; Set the cookie now so next time they will get through.

;

; Use $(url.cookie_domain) to reduce the number of sub-domains

; that get checked.

;

redirect( 302, "(.*)",



6/15

"http://splash.policyexample.bluecoat.com/Splash?$(1)" )

set( exception.response.header.Set-Cookie, \

"splashed=yes;expires=$(cookie_date:minutes.add(5))$(url.cookie_domain)" )

end

Note the use o the line continuation character '\' which must be the last character on the line and ollow spaceor tab.

This action matches the ull URL and then preserves it in the query portion o the redirect URL. It also sets

the splash cookie, so that ater the splash check, a request or the original content will not trigger the splash

check again.

This example sets the cookie to expire in 5 minutes. This duration is useul when doing initial testing, but is

subjecttoclockskewproblems.Othersettingsaremorelikelyordeployment,suchasexpirationatmidnight.

I you choose to use short expiration times or testing, rst ensure that the test station's clock agrees with thetime on the secure proxy appliance. See the Setting the Splash Interval section or urther details.

Note: The expiration time o the cookie is set or the individual domains. The expiration time will also be set orthe cookie in the splash domain. I no expiration time or maximum age is specifed, the cookie will last or thebrowsersession.Thismayresultinmissingsplashopportunities(ifthesessionlastslongerthanthesplashinterval)orsplashingmoreoftenthanrequired(ifthesessionsareshorterthanthesplashinterval).

The next condition will test or URLs directed to the splash page, a URL within our virtual "splash" domain.

; Anything directed to this domain might result in a splash page.

; The original URL will be in the path.

; We'll never emit an IP address, so there's no point in forcing

; an RDNS check.

;dene condition URL_is_splash_page

url.domain.no_lookup=splash.policyexample.bluecoat.com/Splash

end

Note: The URL we use in the example, splash.policyexample.bluecoat.com/Splash, must be defned or yourinstallation. Requests or the domain "my_splash_domain.com" must arrive at the secure proxy appliance thatissued the challenge. For the ProxySG, the domain must be resolvable by DNS queries. For testing purposes"www.bluecoat.com/Splash" will work.

When this condition is true, we will check or the splash cookie. I the splash cookie is present we redirect the

client once again, using the original URL recovered rom the request URL.

; This action is used to redirect the client back to the

; originally requested content,; after a check with the splash domain showed the client had

; already been splashed.

;

dene action redirect_post_splash

redirect( 302,

"http://www\.my_splash_domain\.com/Splash\?(.*)", "$(1)" )

End

I the splash cookie is not present in the request to the splash domain, policy will prepare to return the splash page

exception by recovering the original URL and setting the splash cookie or the splash domain using the ollowing

action.Thesplashpageusestheresultotherewritebyreerencing$(server_url)ortheoriginalcontent.



7/15

; At the Splash Domain during a check, we received the original

; URL in the query.

; This rewrite gives us back the original URL.;

dene action prepare_to_splash

rewrite( url,


set( exception.response.header.Set-Cookie, \

"splashed=yes; expires=$(cookie_date:minutes.add(5))" )

End

In this example we set the expiry or the cookie in the Splash domain to be the same as the expiry o the cookies

in the original domains. This may be inappropriate or many deployments. See Setting the Splash Interval or a

discussion o the issues involved in setting expiry times.

Finally, the policy layer that controls the various states o the splash mechanism, using theseconditions and actions is:

; Policy Layer for Splash Page control

; To prevent innite loops, the rst thing we do is trap

; requests for the splash page

;

; Each time the user visits a new domain, they get redirected

; to the splash page.

; If they've already been splashed, redirect them back to

; where they were going.

; A cookie has already been set for that domain so they will; get through.

;

condition=URL_is_splash_page

condition=splash_cookie_is_present \

action.redirect_post_splash(yes)

; Otherwise they have not been splashed, so splash them.

; We rely on the splash page denition to get them back

; afterwards.

; Note that the URL is in the form

;

;

http://splash.policyexample.bluecoat.com/Splash?original_url,

;

; so the URL must be rewritten to strip off the splash URL

; prex.

; The exception page format uses $(server_url) substitutions

; to pick up the rewritten URL.

;

condition=URL_is_splash_page action.prepare_to_splash(yes) \

exception( user_dened.splash )

; Next we check for requests that already have the splash cookie

; set.

;

condition=splash_cookie_is_present OK



8/15

; just let them through

; Otherwise, if the content type is appropriate, we check to see

; if we should; splash by redirecting the request to the splash domain. If the

; user has

; already been splashed the splash cookie will be offered there.

; Otherwise the user will be splashed. In either case, they will

; eventually re-request the original content.

;

; We set a cookie for the original domain during the redirection,

; so that the post-splash check request for the content will get

; through.

;

condition=can_splash action.check_for_splash(yes)

Notes:

1 The label "splash" that ollows the layer type "Proxy" in this example is valid CPL. This label acts like acomment, but unlike comments it is preserved in the listing o the currently installed policy. It also makes iteasy to locate and reerence layers used or specifc purposes.

2 To let users who present the splash cookie through, we use a rule with the keyword OK. This is a CPL no-optoken and could be omitted in most cases. Use OK rather than allow so as to not override previous accesspolicythatmighthavedeniedaccessforotherreasons(forexample,basedontheclient'ssubnet).

3 Below is an example o the policy:

; Condition denitions

; We can only splash when the user is expecting HTML content,

; and we will not splash explicitly proxied administrators.

;


console_access=no response.header.Content-

Type="text/html"

end

; Anything directed at this domain might result in a splash page.

; The original URL will be in the path.

; We'll never emit an IP address, so there's no point in forcing

; an RDNS check.

;

dene condition URL_is_splash_page

url.domain.no_lookup=splash.policyexample.bluecoat.com/Splashend

; true if we nd the splash cookie

;

dene condition splash_cookie_is_present

request.header.Cookie="splashed=yes"

end

; Policy Layer for Splash Page control

; To prevent innite loops, the rst thing we do is trap



9/15

; requests for the splash page

;

; Each time they visit a new domain, they get redirected to the

; splash page.

; If they've already been splashed, we need to redirect them back

; to where they were going.

; A cookie has already been set for that domain so they can get

; through next time.

;

condition=URL_is_splash_page \

condition=splash_cookie_is_present \

action.redirect_post_splash(yes)

; Otherwise they have not been splashed, so splash them.

; We rely on the splash page denition to get them back

; afterwards.; Note that the URL is in the form

; http://splash.policyexample.bluecoat.com/Splash?original_url,

; so the URL must be rewritten to strip off the splash URL

; prex.

; The exception page format uses $(server_url) substitutions to

; pick up the rewritten URL.

;

condition=URL_is_splash_page action.prepare_to_splash(yes)


; Next we check for requests that already have the splash cookie

; set.

;

condition=splash_cookie_is_present OK

; just let them through

; Otherwise, if the content type is appropriate, we check to see

; if we should splash by redirecting the request to the splash

; domain. If the user has already been splashed the splash

; cookie will be offered there. Otherwise the user will be

; splashed. In either case they will eventually be re-request the

; original content.

;

; We set a cookie for the original domain during the redirection,

; so that the post-splash check request for the content will get

; through.

;

condition=can_splash action.check_for_splash(yes)

; check for need to splash

; If the splash page contains embedded URLs, there may be issues

; pipelining them so we turn pipelining off.

;

condition=URL_is_splash_page pipeline(no)

; Action denitions

; IMPORTANT: This example sets cookie expiry in both the content



10/15

; and splash domains to 5 minutes. The user will be splashed

; roughly every 5 minutes, with a maximum time between splashes

; of 10 minutes (the sum of the two cookie expiries). This is; only useful for testing purposes since it is subject to clock

; skew issues between the client and the Proxy SG.

; To splash once per session, remove the expiry setting.

; To splash once per day, or according to some other schedule,

; set the expiry accordingly.

; For each new domain visited, the user is redirected to

; the splash domain, to see if they've already been splashed.

;

dene action check_for_splash

; Preserve the original URL as part of the redirection, so

; we can do the check and use the original URL to then get the

; content.; Set the cookie now so next time we'll get through.

;

; Use $(url.cookie_domain) to reduce the number of sub-domains

; that get checked.

;

redirect(302, "(.*)",

"http://splash.policyexample.bluecoat.com/Splash?$(1)")

set(response.header.Set-Cookie, "splashed=yes;

expires=$(cookie_date:minutes.add(5))$(url.cookie_domain)")

end

; At the Splash Domain during a check, we received the original

; URL in the query string.

; This rewrite gives us back the original URL.

;

dene action prepare_to_splash

rewrite( url,


set(response.header.Set-Cookie, "splashed=yes;

expires=$(cookie_date:minutes.add(5))")

end

; This action is used to redirect the client back to the

; originally requested content, after a check with the splash

; domain showed the client had already been splashed.

;

dene action redirect_post_splashredirect( 302,


end

Setting the Splash Interval

The splash interval is determined by the lietime o the splash cookies, set in the prepare_to_splash and check_

or_splash actions in this implementation. There are two options here:

Tosplashoneachbrowsersession,omitanyexpiryormax-agecomponentswhensettingthecookie.

Tosplashagainaterarelativeinterval(orexample,anhourromnow),relativecookieexpirytimes



11/15

mustbegenerated.CPLprovidesthe$(cookie_date)substitutiontosupplythecurrenttimeintheormat required by Set-Cookie headers, and a set o modiers to produce osets rom the current time.

For example,

set(response.header.Set-Cookie,"splashed=yes;

expires=$(cookie_date:hours.add(1))")

setsacookiethatexpires1hour,relativetotheclockonthesecureproxyappliance.Seetheollowingtable or urther examples.

Note that the lietimes o the cookies set in the splash domain and the content domains overlap, sothe user may go the sum o the splash domain cookie lietime and the content domain cookie lietimebetween splash page presentations. You may thereore wish to set shorter lietimes or the cookies setinthecontentdomains.Forexample,settingasplashdomaincookieexpiryof10minutesandacontentdomaincookieexpiryof2minutes,wouldmeanthatausermightgo12minutebetweensplashes.

TosplashtheusereachMondaymorning,thefrstothemonth,oronsomesimilarinterval,absolutecookieexpirytimesmustbegenerated.CPLprovidesthe$(cookie_date)substitutiontosupplythecurrent time in the ormat required by Set-Cookie headers, and a set o modiers to advance to the next

desired time interval. See the ollowing table or examples.

Thistablegivesseveralexamplesomodifersthatcouldbeusedin$(cookie_date:modifer).SeetheCPLReerence manual or more details.

modifer eect

:minutes.add(15) expiresin15minutes

:hours.add(2) expires in 2 hours

:day.add(1) expires in 24 hours

:next_date(2:00) expires at 2 am

:next_date(00:00):next_date(2:00) expires at 2 am tomorrow

:next_date(00:00):add.days(1):next_date(2:00) expires at 2am the day ater tomorrow

:next_date(Mon2:00) expires at 2 am Monday morning

:next_date(last22:00) expiresat10pmthelastdayothemonth

:next_date(15Tue2:00) expires at 2am the third Tuesday o the month

Note that the third Tuesday o the month must be

betweenthe15thand21st.

Theexpressionadvanceszeroormoresecondstothe15tho the month, and then advances zero or more seconds to

Tuesday,thenadvances0ormoresecondsto2am.

:add(2):next_date(2:00) i it's earlier than midnight, expire at 2am, i ater, expireat 2am the ollowing day.

:days.add(2):next_date(1) expires at midnight the last day o the month, except i

we'rewithin2daysothelastday(inwhichcasewegettilltheendonextmonth)



12/15

Note: Setting the expiry time is done with reerence to the secure proxy appliance's clock, but is interpretedrelativetotheuser'sclock.Therefore,usingthistechniquetosetshortexpirytimesissubjecttoclockskew

problems. Suppose, or example, that the cookie expiry is set to 5 minutes into the uture. This is done relativeto the clock on the secure proxy appliance. I the client's clock is more than 5 minutes ahead o the secure proxyappliance's clock, rom the client's view the cookie will already have expired when it is set, with the result thatuser will be splashed continually. We would recommend against using short expiry times or this reason. Touse short expiry times or testing, frst ensure that the test station's clock agrees with the time on the secureproxy appliance.

When setting relative rather than absolute expiry times, remember that the lietimes o the cookies in the

individual content domains and the splash domain will overlap, so the maximum time between splashes may be

the sum o the two expiry times. To minimize this, you may choose to shorten the expiry o the individual content

domains relative to the splash domain interval.

DeploymentThe layer is probably best dened through the Local policy le to avoid accidental changes to

the logic that implements splashing. This layer is a boilerplate or most splash page applications and does not

require user modication. The Local policy le should ollow the VPM le in the policy le order. The parameters

o the splash behavior that are o interest to users include:

Thecontentsothesplashpage-setthroughtheexceptionpageormat

Thetimebeorethesplashpageisreplacedwiththeoriginallyrequestedcontentalsosetthroughtheexceptionpageormat(althoughthiscouldalsobesetinthepolicyactions,seeVariations)

Thesplashinterval-determinedbythecookieexpirytime

Thesplashdomain-thisdomainismentionedseveraltimesinthepolicyconditionsandactions.Itisunlikely to change ater initial deployment

This implies that we can provide the VPM with control over the splash page behavior by dening the ollowing

actions in the VPM, rather than in the local policy le:

check_or_splash

prepare_to_splash

Remember that to avoid compilation errors, any conditions or actions should be dened in the VPM beore they

are reerenced in the Local policy le.

TestingTo test your splash policy:

1 Setashortsplashinterval(the5minuteintervalusedinthesampleisappropriate)

2 Browse to various domains

The splash page should be presented ater each interval, as specied.



13/15

Variations

This TechBrie cannot cover all o the variations that might be required in the eld, nor all o the various CPL

eaturesthatmightbeusedtosupportfeldrequirements.Herewepresentjustaewothesimplerpossibilities.

Requiring Explicit Acknowledgment

The sample splash page automatically redirects the user to the requested content. To require users to take an

explicitaction(clickingonalink)toviewtheoriginallyrequestedcontent,removetheollowinglineromthesplash page ormat.

Recall that the sample page already includes a link to the original content in the body o the message. Ensure

that such a link appears somewhere in the body o the page.

Click here to continue.

Note that the URL used in this link is again the server_url, since this is the original URL recovered rom therequest URL by a rewrite action.

Using Non-Exception Based Splash Pages

Rather than dening the splash page as an exception that can be served directly rom the secure proxy

appliance, some clients may preer to load the splash page onto a server. To begin, all occurrences o

splash.policyexample.bluecoat.com/Splash

need to be customized to point to the correct location. As well, the policy rule

condition=URL_is_splash_page action.prepare_to_splash(yes) \


should be changed to:

condition=URL_is_splash_page action.splash(yes)

To decide what the splash action should do, consider how the user will subsequently retrieve the originally

requested content. There are three alternatives:

1 The user must re-issue the original request manually, or example using the browser's Reresh button.

The splash page text should include appropriate instructions.

In this case, there is no point in preserving the original URL in the splash request, nor in recovering it

rom the request. The splash action should be:

dene action splash

redirect( 302, "(.*)",

"splash.policyexample.bluecoat.com/Splash" ) ; the splash page

URL

End



14/15

2 Policy adds a Reresh header to the splash page response. The Reresh header uses the recovered

original URL. The content will be rereshed ater the interval specied in the header. The splash page

should still contain instructions or the case when the user agent does not support rereshes. The

splash action

would be:

dene action splash

redirect( 302, "(.*)",

"splash.policyexample.bluecoat.com/Splash" ) ; the splash page

URL

set(response.header.Refresh, "10; url=$(server_url)")

end

3 In order to provide access to the originally requested content, custom sotware could be loaded on

the server to generate the appropriate embedded link or reresh header rom the query portion o

the request.

I the splash page contains links to embedded content, pipelining the embedded content may cause issues or

some deployments. Turn pipelining o or the splash page by adding:

; If the splash page contains embedded URLs, there may be

; issues pipelining them so we turn pipelining off.

;

condition=URL_is_splash_page pipeline(no)

Splashing Only Specic Users

I you want to limit splashing to specic user populations, dene a condition such as:

dene condition splash_groups

group=splash_group1

...

End

and add this to the can_splash condition denition:

; We can only splash only the selected users, and

; only when the user is expecting HTML content.

;


condition=splash_groups response.header.Content-

Type="text/html"End

I the layer is dened in the local policy le, a somewhat more ecient alternative is to guard

the layer with the new condition:

condition=splash_groups

The splash_groups condition might be the dened in the VPM and the rest o the changes kept to the Local le.



15/15

Splashing Dierent User Populations

I you want to present dierent splash pages to dierent user populations, you will need to duplicate most o

the conditions, actions and rules or each. It may be simplest to treat each population in its own layer, using the

technique described above or Splashing Only Specic Users.

Conclusion

This TechBrie has provided the inormation and steps to create a splash page or an enterprise network

environment. A splash page can be used to communicate company news, corporate announcements and policies

toanentireorganization.ForadditionalinormationregardingtheContentPolicyLanguage(CPL)orothervariables please reer to your Blue Coat documentation or contact a Blue Coat Systems engineer in your area.

Copyright2009BlueCoatSystems,Inc.Allrightsreservedworldwide.NopartothisdocumentmaybereproducedbyanymeansnortranslatedtoanyelectronicmediumwithoutthewrittenconsentoBlueCoatSystems,Inc.Specifcations

aresubjecttochangewithoutnotice.Inormationcontainedinthisdocumentisbelievedtobeaccurateandreliable,however,BlueCoatSystems,Inc.assumesnoresponsibilityoritsuse.BlueCoat,ProxySG,PacketShaper,ProxyClientand

Blue Coat Systems, Inc.www.bluecoat.com

Corporate HeadquartersSunnyvale,CAUSA//+1.408.220.2200

EMEA HeadquartersHampshire,UK//+44.1252.554600

APAC HeadquartersHongKong//+852.3476.1000


Documents

Creating Splash Pages