mirror of
https://github.com/Frooodle/Stirling-PDF.git
synced 2026-03-04 02:20:19 +01:00
23f872823d
# Description of Changes - **What was changed** - Updated `PipelineProcessor#sendWebRequest(...)` to stop forcing `Content-Type: multipart/form-data` and to stop manually writing the multipart body via `FormHttpMessageConverter`. - Switched to `RestTemplate#httpEntityCallback(...)` (`RequestCallback`) so Spring’s configured message converters handle multipart serialization (including boundary generation) correctly. - Made `X-API-KEY` header conditional (only added when non-null/non-empty). - Added a unit test (`sendWebRequestDoesNotForceContentType`) to ensure `Content-Type` is not explicitly set on the outgoing request headers and that the request succeeds end-to-end using mocked `RestTemplate` behavior. - **Why the change was made** - The server-side error `org.eclipse.jetty.http.BadMessageException: 400: bad multipart` with `EOFException: unexpected EOF` indicates the multipart request can be malformed (commonly due to boundary/content-type mismatches or prematurely terminated streams). Manually setting the multipart content type and writing the body can bypass Spring’s normal boundary handling and lead to invalid multipart payloads. Letting `RestTemplate` handle it ensures correct formatting. --- This pull request updates how multipart web requests are sent in the pipeline processor to avoid forcing the `Content-Type` header for multipart requests, allowing the message converter to set it automatically. It also adds a new test to ensure this behavior. The main changes are focused on improving multipart request handling and increasing test coverage. **Multipart request handling improvements:** * Refactored `PipelineProcessor.runPipelineAgainstFiles` to avoid explicitly setting the `Content-Type` header to `multipart/form-data`, letting the message converter set the appropriate boundary and content type instead. This helps prevent issues with incorrect boundaries and improves compatibility with multipart requests. * Updated imports in `PipelineProcessor.java` to remove unused `FormHttpMessageConverter` and add `RequestCallback`. **Testing enhancements:** * Added a new test `sendWebRequestDoesNotForceContentType` in `PipelineProcessorTest.java` to verify that the `Content-Type` header is not set explicitly and is left for the message converter to handle. This test uses mocking to simulate the request and response flow. * Added necessary imports in `PipelineProcessorTest.java` to support new test logic and mocking. [[1]](diffhunk://#diff-1a45e7b37023bd3a9580ab24d7025bb359cb8891c486111d372c0557f817b3edR7-R8) [[2]](diffhunk://#diff-1a45e7b37023bd3a9580ab24d7025bb359cb8891c486111d372c0557f817b3edR18-R27) --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md#6-testing) for more details.
Stirling PDF - The Open-Source PDF Platform
Stirling PDF is a powerful, open-source PDF editing platform. Run it as a personal desktop app, in the browser, or deploy it on your own servers with a private API. Edit, sign, redact, convert, and automate PDFs without sending documents to external services.
Key Capabilities
- Everywhere you work - Desktop client, browser UI, and self-hosted server with a private API.
- 50+ PDF tools - Edit, merge, split, sign, redact, convert, OCR, compress, and more.
- Automation & workflows - No-code pipelines direct in UI with APIs to process millions of PDFs.
- Enterprise‑grade - SSO, auditing, and flexible on‑prem deployments.
- Developer platform - REST APIs available for nearly all tools to integrate into your existing systems.
- Global UI - Interface available in 40+ languages.
For a full feature list, see the docs: https://docs.stirlingpdf.com
Quick Start
docker run -p 8080:8080 docker.stirlingpdf.com/stirlingtools/stirling-pdf
Then open: http://localhost:8080
For full installation options (including desktop and Kubernetes), see our Documentation Guide.
Resources
Support
- Community Discord
- Bug Reports: Github issues
Contributing
We welcome contributions! Please see CONTRIBUTING.md for guidelines.
For development setup, see the Developer Guide.
For adding translations, see the Translation Guide.
License
Stirling PDF is open-core. See LICENSE for details.