FOUR-20933: Implement ETag Caching for Screens Data

[eiresendez]

This PR introduces foundational support for ETag-based caching in the application. The implementation includes a middleware to handle HTTP conditional requests and an extensible manager to generate ETags based on different strategies.

Solution

1. ETag Middleware (HandleEtag):

• Handles If-None-Match headers for caching.
• Supports safe HTTP methods (GET, HEAD).
• Responds with 304 Not Modified when ETag matches.
• Restores the original HTTP method after processing (HEAD to GET).

2. ETag Manager:

• Generates default ETags using an MD5 hash of the response content.
• Supports custom algorithms (e.g., SHA-256) through callbacks.

3. Tests:

• Verify default ETag generation using MD5.
• Ensure custom ETag generation works via callback.
• Validate IfNoneMatch middleware behavior for matching and non-matching ETags.

How to Test

1. Initial Request:

• The first time the endpoint is called, a 200 status response is returned.
• The response content is retrieved from the server and cached.

2. Subsequent Requests (Page Refresh):

• On subsequent page refreshes, since the response is already cached, a 304 status is returned.
• This improves response time and reduces bandwidth usage.

3. Content Updates:

• If the response content changes (e.g., the screen is modified or updated) a 200 status is returned again and the new content is reloaded.
• On subsequent refreshes, the updated content will remain cached and the server will respond with 304 status.

Endpoints:
Screen Responses in Core:
GET https://processmaker.test/api/1.1/tasks/{param_1}/screen?include=screen,nested&screen_version={param_2}

Screen Responses in Web Entry:
GET https://processmaker.test/api/1.0/webentry/{param_1}/{param_2}/screens/{param_3}?include=nested

Related Tickets & Packages

• FOUR-20933
• Package Web Entry PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

[estebangallego]

Works as expected!

[eiresendez]

This PR introduces foundational support for ETag-based caching in the application. The implementation includes a middleware to handle HTTP conditional requests and an extensible manager to generate ETags based on different strategies.

Solution

1. ETag Middleware (HandleEtag):

• Handles If-None-Match headers for caching.
• Supports safe HTTP methods (GET, HEAD).
• Responds with 304 Not Modified when ETag matches.
• Restores the original HTTP method after processing (HEAD to GET).

2. ETag Manager:

• Generates default ETags using an MD5 hash of the response content.
• Supports custom algorithms (e.g., SHA-256) through callbacks.

3. Tests:

• Verify default ETag generation using MD5.
• Ensure custom ETag generation works via callback.
• Validate IfNoneMatch middleware behavior for matching and non-matching ETags.

How to Test

1. Initial Request:

• The first time the endpoint is called, a 200 status response is returned.
• The response content is retrieved from the server and cached.

2. Subsequent Requests (Page Refresh):

• On subsequent page refreshes, since the response is already cached, a 304 status is returned.
• This improves response time and reduces bandwidth usage.

3. Content Updates:

• If the response content changes (e.g., the screen is modified or updated) a 200 status is returned again and the new content is reloaded.
• On subsequent refreshes, the updated content will remain cached and the server will respond with 304 status.

Endpoints:
Screen Responses in Core:
GET https://processmaker.test/api/1.1/tasks/{param_1}/screen?include=screen,nested&screen_version={param_2}

Screen Responses in Web Entry:
GET https://processmaker.test/api/1.0/webentry/{param_1}/{param_2}/screens/{param_3}?include=nested

Related Tickets & Packages

• FOUR-20933
• Package Web Entry PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

[estebangallego]

Works as expected!

[eiresendez]

This PR introduces foundational support for ETag-based caching in the application. The implementation includes a middleware to handle HTTP conditional requests and an extensible manager to generate ETags based on different strategies.

Solution

1. ETag Middleware (HandleEtag):

• Handles If-None-Match headers for caching.
• Supports safe HTTP methods (GET, HEAD).
• Responds with 304 Not Modified when ETag matches.
• Restores the original HTTP method after processing (HEAD to GET).

2. ETag Manager:

• Generates default ETags using an MD5 hash of the response content.
• Supports custom algorithms (e.g., SHA-256) through callbacks.

3. Tests:

• Verify default ETag generation using MD5.
• Ensure custom ETag generation works via callback.
• Validate IfNoneMatch middleware behavior for matching and non-matching ETags.

How to Test

1. Initial Request:

• The first time the endpoint is called, a 200 status response is returned.
• The response content is retrieved from the server and cached.

2. Subsequent Requests (Page Refresh):

• On subsequent page refreshes, since the response is already cached, a 304 status is returned.
• This improves response time and reduces bandwidth usage.

3. Content Updates:

• If the response content changes (e.g., the screen is modified or updated) a 200 status is returned again and the new content is reloaded.
• On subsequent refreshes, the updated content will remain cached and the server will respond with 304 status.

Endpoints:
Screen Responses in Core:
GET https://processmaker.test/api/1.1/tasks/{param_1}/screen?include=screen,nested&screen_version={param_2}

Screen Responses in Web Entry:
GET https://processmaker.test/api/1.0/webentry/{param_1}/{param_2}/screens/{param_3}?include=nested

Related Tickets & Packages

• FOUR-20933
• Package Web Entry PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

[estebangallego]

Works as expected!

[eiresendez]

This PR introduces foundational support for ETag-based caching in the application. The implementation includes a middleware to handle HTTP conditional requests and an extensible manager to generate ETags based on different strategies.

Solution

1. ETag Middleware (HandleEtag):

• Handles If-None-Match headers for caching.
• Supports safe HTTP methods (GET, HEAD).
• Responds with 304 Not Modified when ETag matches.
• Restores the original HTTP method after processing (HEAD to GET).

2. ETag Manager:

• Generates default ETags using an MD5 hash of the response content.
• Supports custom algorithms (e.g., SHA-256) through callbacks.

3. Tests:

• Verify default ETag generation using MD5.
• Ensure custom ETag generation works via callback.
• Validate IfNoneMatch middleware behavior for matching and non-matching ETags.

How to Test

1. Initial Request:

• The first time the endpoint is called, a 200 status response is returned.
• The response content is retrieved from the server and cached.

2. Subsequent Requests (Page Refresh):

• On subsequent page refreshes, since the response is already cached, a 304 status is returned.
• This improves response time and reduces bandwidth usage.

3. Content Updates:

• If the response content changes (e.g., the screen is modified or updated) a 200 status is returned again and the new content is reloaded.
• On subsequent refreshes, the updated content will remain cached and the server will respond with 304 status.

Endpoints:
Screen Responses in Core:
GET https://processmaker.test/api/1.1/tasks/{param_1}/screen?include=screen,nested&screen_version={param_2}

Screen Responses in Web Entry:
GET https://processmaker.test/api/1.0/webentry/{param_1}/{param_2}/screens/{param_3}?include=nested

Related Tickets & Packages

• FOUR-20933
• Package Web Entry PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

[estebangallego]

Works as expected!

[eiresendez]

This PR introduces foundational support for ETag-based caching in the application. The implementation includes a middleware to handle HTTP conditional requests and an extensible manager to generate ETags based on different strategies.

Solution

1. ETag Middleware (HandleEtag):

• Handles If-None-Match headers for caching.
• Supports safe HTTP methods (GET, HEAD).
• Responds with 304 Not Modified when ETag matches.
• Restores the original HTTP method after processing (HEAD to GET).

2. ETag Manager:

• Generates default ETags using an MD5 hash of the response content.
• Supports custom algorithms (e.g., SHA-256) through callbacks.

3. Tests:

• Verify default ETag generation using MD5.
• Ensure custom ETag generation works via callback.
• Validate IfNoneMatch middleware behavior for matching and non-matching ETags.

How to Test

1. Initial Request:

• The first time the endpoint is called, a 200 status response is returned.
• The response content is retrieved from the server and cached.

2. Subsequent Requests (Page Refresh):

• On subsequent page refreshes, since the response is already cached, a 304 status is returned.
• This improves response time and reduces bandwidth usage.

3. Content Updates:

• If the response content changes (e.g., the screen is modified or updated) a 200 status is returned again and the new content is reloaded.
• On subsequent refreshes, the updated content will remain cached and the server will respond with 304 status.

Endpoints:
Screen Responses in Core:
GET https://processmaker.test/api/1.1/tasks/{param_1}/screen?include=screen,nested&screen_version={param_2}

Screen Responses in Web Entry:
GET https://processmaker.test/api/1.0/webentry/{param_1}/{param_2}/screens/{param_3}?include=nested

Related Tickets & Packages

• FOUR-20933
• Package Web Entry PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

[estebangallego]

Works as expected!

[eiresendez]

This PR introduces foundational support for ETag-based caching in the application. The implementation includes a middleware to handle HTTP conditional requests and an extensible manager to generate ETags based on different strategies.

Solution

1. ETag Middleware (HandleEtag):

• Handles If-None-Match headers for caching.
• Supports safe HTTP methods (GET, HEAD).
• Responds with 304 Not Modified when ETag matches.
• Restores the original HTTP method after processing (HEAD to GET).

2. ETag Manager:

• Generates default ETags using an MD5 hash of the response content.
• Supports custom algorithms (e.g., SHA-256) through callbacks.

3. Tests:

• Verify default ETag generation using MD5.
• Ensure custom ETag generation works via callback.
• Validate IfNoneMatch middleware behavior for matching and non-matching ETags.

How to Test

1. Initial Request:

• The first time the endpoint is called, a 200 status response is returned.
• The response content is retrieved from the server and cached.

2. Subsequent Requests (Page Refresh):

• On subsequent page refreshes, since the response is already cached, a 304 status is returned.
• This improves response time and reduces bandwidth usage.

3. Content Updates:

• If the response content changes (e.g., the screen is modified or updated) a 200 status is returned again and the new content is reloaded.
• On subsequent refreshes, the updated content will remain cached and the server will respond with 304 status.

Endpoints:
Screen Responses in Core:
GET https://processmaker.test/api/1.1/tasks/{param_1}/screen?include=screen,nested&screen_version={param_2}

Screen Responses in Web Entry:
GET https://processmaker.test/api/1.0/webentry/{param_1}/{param_2}/screens/{param_3}?include=nested

Related Tickets & Packages

• FOUR-20933
• Package Web Entry PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

[estebangallego]

Works as expected!

[eiresendez]

This PR introduces foundational support for ETag-based caching in the application. The implementation includes a middleware to handle HTTP conditional requests and an extensible manager to generate ETags based on different strategies.

Solution

1. ETag Middleware (HandleEtag):

• Handles If-None-Match headers for caching.
• Supports safe HTTP methods (GET, HEAD).
• Responds with 304 Not Modified when ETag matches.
• Restores the original HTTP method after processing (HEAD to GET).

2. ETag Manager:

• Generates default ETags using an MD5 hash of the response content.
• Supports custom algorithms (e.g., SHA-256) through callbacks.

3. Tests:

• Verify default ETag generation using MD5.
• Ensure custom ETag generation works via callback.
• Validate IfNoneMatch middleware behavior for matching and non-matching ETags.

How to Test

1. Initial Request:

• The first time the endpoint is called, a 200 status response is returned.
• The response content is retrieved from the server and cached.

2. Subsequent Requests (Page Refresh):

• On subsequent page refreshes, since the response is already cached, a 304 status is returned.
• This improves response time and reduces bandwidth usage.

3. Content Updates:

• If the response content changes (e.g., the screen is modified or updated) a 200 status is returned again and the new content is reloaded.
• On subsequent refreshes, the updated content will remain cached and the server will respond with 304 status.

Endpoints:
Screen Responses in Core:
GET https://processmaker.test/api/1.1/tasks/{param_1}/screen?include=screen,nested&screen_version={param_2}

Screen Responses in Web Entry:
GET https://processmaker.test/api/1.0/webentry/{param_1}/{param_2}/screens/{param_3}?include=nested

Related Tickets & Packages

• FOUR-20933
• Package Web Entry PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

[estebangallego]

Works as expected!

[eiresendez]

This PR introduces foundational support for ETag-based caching in the application. The implementation includes a middleware to handle HTTP conditional requests and an extensible manager to generate ETags based on different strategies.

Solution

1. ETag Middleware (HandleEtag):

• Handles If-None-Match headers for caching.
• Supports safe HTTP methods (GET, HEAD).
• Responds with 304 Not Modified when ETag matches.
• Restores the original HTTP method after processing (HEAD to GET).

2. ETag Manager:

• Generates default ETags using an MD5 hash of the response content.
• Supports custom algorithms (e.g., SHA-256) through callbacks.

3. Tests:

• Verify default ETag generation using MD5.
• Ensure custom ETag generation works via callback.
• Validate IfNoneMatch middleware behavior for matching and non-matching ETags.

How to Test

1. Initial Request:

• The first time the endpoint is called, a 200 status response is returned.
• The response content is retrieved from the server and cached.

2. Subsequent Requests (Page Refresh):

• On subsequent page refreshes, since the response is already cached, a 304 status is returned.
• This improves response time and reduces bandwidth usage.

3. Content Updates:

• If the response content changes (e.g., the screen is modified or updated) a 200 status is returned again and the new content is reloaded.
• On subsequent refreshes, the updated content will remain cached and the server will respond with 304 status.

Endpoints:
Screen Responses in Core:
GET https://processmaker.test/api/1.1/tasks/{param_1}/screen?include=screen,nested&screen_version={param_2}

Screen Responses in Web Entry:
GET https://processmaker.test/api/1.0/webentry/{param_1}/{param_2}/screens/{param_3}?include=nested

Related Tickets & Packages

• FOUR-20933
• Package Web Entry PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

[estebangallego]

Works as expected!