Applies to Pega Platform 7.2-8.6

This article provides answers to frequently asked questions about static content and static content requests.

Static content

Static content is information that is extracted once from a rule to an HTTP server or Web server. It is unaffected by user input, such as the use of an application or the content of user clipboards.

Answers to frequently asked questions

How to deploy static content to the Edge server? 
How to identify if a request is a static content request?
What causes HTTP response 304 for a static content request?
How to verify that Pega-RULES cookie is not sent to the Pega server along with a static content request?
Why does HTTP response 304 occur instead of HTTP response 400 for a non-existing static content request?
Can the Temp directory be deleted when the disk is full of content in the StaticContent directory?
How is the unused assembled content cleaned?
Which are the debug loggers that help troubleshoot issues related to serving a static content request?
What are the artifacts that must be gathered before starting to troubleshoot issues related to static content requests?
What actions must be taken when the content-type for a static content request is incorrect and the user is unable to recognize the response?
Why does old data persist despite updating the static content rule (Rule-File-)?

How to deploy static content to the Edge server? 

Learn the procedure to deploy static content to an Edge server by clicking the following URL:

Deploying Static content to an Edge server

How to identify if a request is a static content request?

Requests that end with a file extension are static content requests. Static content requests do not contain thread names.

Example for static content requests,

• http://sde-85-cam.eng.rpega.com/prweb/app/AppAlias_/gFLICWRhd0CfR1wHoXP…

• http://sde-85-cam.eng.rpega.com/prweb/datacontent/Image/webwb/DriverLic… 

What causes HTTP response 304 for a static content request?

HTTP response 304 occurs for a static content request under the following conditions:

• When the static content request is sent to the Pega server without the Pega-RULES cookie
• When the static content file or rule is not present in the Pega server
• When an error occurs at the Pega server side while processing the static content request
• When the prconfig or Dynamic System Setting (DSS) for authentication/usepreauthenticationcookie is set to False (Default and recommended value is True)

How to verify that Pega-RULES cookie is not sent to the Pega server along with a static content request?

Perform the following steps to verify if Pega-RULES cookie is not sent to the Pega server along with the static content request:

1. Enable Debug on the LogHttpRequest logger.

2. Fire a Static content request.

3. Verify if the cookie attribute logged contains Pega-RULES.

Example of a Pega-RULES cookie in a sample HTTP request,

Why does HTTP response 304 occur instead of HTTP response 400 for a non-existing static content request?

Static content requests are cached requests that are cached by browsers. Through HTTP response 304, the Pega server indicates to the browser that it can use the cached content. This is a recovery mechanism. This is a misleading status and can be addressed. However, the design is not changed because the application or client relying on status code might break.

Can the Temp directory be deleted when the disk is full of content in the StaticContent directory?

Some users have reported that the old static content is not cleared, resulting in huge space occupied by static content on the file system.

To resolve the issue, delete the content of the StaticContent directory manually. The issue is addressed in Pega Platform 8.4.1.

All the static content files stored in the file system are part of the static content cache. The files are retrieved and stored in the cache upon the next request.

How is the unused assembled content cleaned?

The DeleteUnusedStaticContentFiles agent deletes the unused assembled static content in the database.

Which are the Debug loggers that help troubleshoot issues related to serving a static content request?

Enable the following Debug loggers when an issue with serving a static content request occurs:

• com.pega.pegarules.web.staticcontent.StaticContentClient

• com.pega.pegarules.exec.internal.basic.staticcontent.StaticContentResolverImpl

What are the artifacts that must be gathered before starting to troubleshoot issues related to static content requests?

Collect the following artifacts when an issue with static content requests occurs:

1. Fiddler trace

2. Pega Rules Log files after enabling Debug on the following Loggers:
   - com.pega.pegarules.web.staticcontent.StaticContentClient
   - com.pega.pegarules.exec.internal.basic.staticcontent.StaticContentResolverImpl
   - LogHttpRequest

What actions must be taken when the content-type for a static content request is incorrect and the user is unable to recognize the response?

Some issues are reported where static content requests fail with HTTP response 404 (for example, SA-83904). The content-type in Response headers turns incorrect when the content-type header in response is set incorrectly.

The following steps are run to set the content-type header in the response:

1. The server performs a lookup for the MIME type mappings in web.xml.

2. The MIME type is set to content-type based on the file extension.

For Pega Platform 8.5 and earlier versions

To resolve the issue, add a new MIME type entry in web.xml.

Example for MIME type entry,

<mime-mapping> 

    <extension>gif</extension> 

    <mime-type>image/gif</mime-type> 

</mime-mapping>

All the Web or Application servers support most of the MIME types. The MIME Mappings are defined in the Web server’s common web.xml (for example, Tomcat <CATALINA_HOME>/conf/web.xml) and in the application specific web.xml (for example, prweb/WEB-INF/web.xml). Hence, during a MIME type lookup, the server performs the lookup in both common web.xml and application-specific web.xml.

When the content-type in Response headers is incorrect and you are unable to recognize the response, go to My Support Portal to create a support case For an issue I’m having (INC). Attach the following artifacts to your incident (INC):

• Fiddler or Chrome network trace

• Application or Web server details (name, version, and so on)

• Common web.xml file (<CATALINA_HOME>/conf/web.xml)

• Application-specific web.xml (prweb.war/WEB-INF/web.xml)

Alternatively, perform the following local change:

1. Edit web.xml in prweb.war.

2. Add the required MIME Mapping.

For Pega Platform 8.6 and later versions

Configure MIME type with the following Data-Admin-System Settings (DASS) in the comma separated, Key Value Pair format:

• DASS Name : "web/mimetypes"

• Owning-RuleSet : "Pega-Engine"

• Format : <file_extension>=<mimetype/subtype>;<charset> (eg:vbs=application/vbs, xml=text/xml;charset="UTF-8")

Why does old data persist despite updating the static content rule (Rule-File-)?

Static content files load to the File system from the database while serving the request for the first time. The same content is served from the File system for the subsequent requests. The File system serves as the static content cache.

The static content cache is invalidated on all the nodes in the cluster when a file is saved. The Rule-File-: Validate activity performs the static content cache invalidation.

The static content cache is not invalidated if the user updates the content of a static content file using the Rule-Obj-Save activity method as Rule-File-:Validate is not invoked in the flow.