• PDF


    • PDF

    Article summary

    Service Versions (Image tags)

    ServiceContainer RepositoryVersion

    Helm Chart Versions

    ChartChart RepositoryVersion

    New Features

    Asynchronous API

    Introducing the first release of the Glasswall Halo Asynchronous API. For more information, including a comparison with the existing Synchronous API.

    Asynchronous APIs are designed to handle concurrent operations and non-blocking I/O, allowing Glasswall Halo to efficiently manage resources and respond to multiple requests simultaneously.

    • Non-Blocking Operations: the Asynchronous API allows you to initiate an operation and continue processing other tasks without waiting for the operation to complete. You can retrieve the result of a request up to a default configured time of 60 minutes before data is cleaned up.
    • Scalability: The Asynchronous API is well-suited to building scalable systems. It can handle a large number of concurrent requests without significant performance degradation, making it ideal for high-traffic applications.
    • Long-Running Tasks: The Asynchronous API is suitable for handling long-running tasks. If your use-case is to perform CDR on larger or more complex files, the Asynchronous API may be the better option.

    Synchronous API

    • Updates to Export functionality including the new Text Dump feature.

      • The Export Text Dump feature offers a convenient option to generate a comprehensive text file that includes all the content from the input file being exported. This text dump file is automatically created and saved in the same ZIP as the output files.
    • Enhanced security of response headers returned by all endpoints, including:

      • cache-control: no-store - To prevent sensitive information from being cached.
      • content-security-policy: frame-ancestors 'none' - To protect against drag-and-drop style clickjacking attacks.
      • strict-transport-security: max-age=31536000; includeSubDomains - To require connections over HTTPS and to protect against spoofed certificates.
      • x-content-type-options: nosniff - To prevent browsers from performing MIME sniffing, and inappropriately interpreting responses as HTML.
      • x-frame-options: DENY - To protect against drag-and-drop style clickjacking attacks.



    • Tooltips: general improvements have been made to the padding and alignment of tooltips throughout Cleanroom.
    • Clean file downloads: Clean files can no longer be downloaded whilst file processing is in progress.
    • File limits: when processing over 100 files outside of Trial mode in Cleanroom, a new pop-up will appear preventing processing from taking place.
    • Archives: files inside archives that were allowed by the Content Management Policy can now be downloaded.
    • Archives: an issue with GZip files has been fixed and GZips are now correctly processed in Cleanroom. As a result of this, a compressed file inside a GZip can now be downloaded.
    • Archives: compressed files inside BZip files can now be downloaded.

    Synchronous API

    • Archives: an issue with allowed files has been resolved, and the archive manifest no longer erroneously reports allowed files as errored.
    • Archives: the processing of complex archives containing a large amount of files no longer creates a response indicating there was an issue with connecting to the Sync API.

    We appreciate your continued support and value your feedback. If you encounter any further issues or have any questions, please don't hesitate to contact our support team.

    Known Issues

    • When using the V2 endpoint for archive file type detection, the returned file type is erroneously displayed as "unknown" instead of "archive."

      • Impact: This issue affects users relying on accurate file type detection through the V2 endpoint for archives, as it may lead to incorrect categorization of files.
    • In the Asynchronous API, a 500 response is returned when retrieving an archive containing files that caused errors during processing.

      • Impact: This issue is caused by archives containing 'errored' files, including files that cause an error response from the Embedded Engine. The archive manifest will not contain an 'errored' section.
    • In the Asynchronous API, when a critical error occurs in the Embedded Engine, a 204 response is sometimes returned indicating a file is still processing.

      • Impact: This issue affects users attempting to retrieve the results of a request, the results will not be populated for these files.


    API Documentation

    Glasswall Documentation

    Clean Room

    Archive Support Documentation

    Licensing Documentation

    Asynchronous API Documentation

    Was this article helpful?

    What's Next