Ошибка при попытке повторной отправки HTTPЗапроса с телом

[Bayselonarrend]

Опишите ошибку
Попытка отправить один и тот же HTTPЗапрос с телом приводит к ошибке Внешнее исключение (System.ObjectDisposedException): Cannot access a closed Stream.

Воспроизведение ошибки

HTTPЗапрос = Новый HTTPЗапрос("/");
HTTPЗапрос.УстановитьТелоИзСтроки("yo");

Соединение = Новый HTTPСоединение("https://1c.ru");

Ответ = Соединение.ВызватьHTTPМетод("POST", HTTPЗапрос);
Ответ = Соединение.ВызватьHTTPМетод("POST", HTTPЗапрос);

Ожидаемое поведение
В 1С такое поведение не наблюдается

Окружение

• ОС: Windows 11
• Версия: 2.0.0 RC7, 2.0.0 RC8

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• 1.9.3.15 Валится скрипт на строке СоединениеHTTP.ВызватьHTTPМетод #1598
• Исключение не перехватывает попыткой в случае если была вложенная попытка #1498
• Зависание при порционном чтении двоичных данных из TCP-соединения #1471
• (System.ArgumentNullException): Значение не может быть неопределенным #1592

🔗 Related PRs

#1618 - Использование потока httpResponse без вычитывания по возможности [merged]

👤 Suggested Assignees

• unichkin
• sfaqer
• salexdv
• tormozit
• asosnoviy

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Approach

Fix the ObjectDisposedException that occurs when reusing an HTTPRequest object with a body for multiple HTTP calls. The issue stems from the stream being disposed after the first request, making it unavailable for subsequent requests.

Observations

The OneScript.StandardLibrary HTTP implementation uses an interface-based design for request bodies. IHttpRequestBody has two main implementations: HttpRequestBodyBinary (using FileBackingStream for in-memory/file-backed storage) and HttpRequestBodyFile (using FileStream from a file path). The HttpConnectionContext class handles HTTP transmission using the legacy HttpWebRequest API. When sending requests, it obtains the body stream via GetDataStream() and copies it to the request stream. The current implementation incorrectly disposes the cached stream after each request, preventing reuse.

Assumptions

Assumption 1: Should GetDataStream() return a cached stream reference or create fresh streams for each call?

Options Considered:

• Return cached references (current behavior): Streams are owned by IHttpRequestBody and callers receive borrowed references
• Create fresh streams: Each GetDataStream() call creates a new stream that callers own and dispose

Chosen Option: Return cached references (current behavior): Streams are owned by IHttpRequestBody and callers receive borrowed references

Rationale: Keep cached references. This aligns with existing implementation patterns (FileBackingStream usage, seek-to-reset behavior), matches test expectations for object reuse, and avoids unnecessary memory allocation. The IHttpRequestBody.Dispose() method is already responsible for cleaning up the stream, so callers should not dispose borrowed references.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Fix Stream Disposal in HTTP Request Transmission

This phase addresses the root cause by preventing premature stream disposal and ensuring streams can be reused across multiple HTTP calls.

Task 1: Remove Stream Disposal from SetRequestBody

Eliminate the using statement that disposes the request body stream in HttpConnectionContext.cs

• Modify the SetRequestBody() method in src/OneScript.StandardLibrary/Http/HttpConnectionContext.cs (lines 368-386) to remove the outer using(stream) block
• Keep the inner using(var requestStream = webRequest.GetRequestStream()) block for proper disposal of the web request stream
• The request body stream should remain open after copying data to the HTTP request, allowing the IHttpRequestBody object to manage its lifecycle via its Dispose() implementation

Task 2: Ensure Stream Position Reset in File-Based Bodies

Add position reset capability to HttpRequestBodyFile to match the reusability pattern of HttpRequestBodyBinary

• Update GetDataStream() method in src/OneScript.StandardLibrary/Http/HttpRequestBodyFile.cs to seek to position 0 before returning the stream
• Follow the same pattern as HttpRequestBodyBinary.GetDataStream() which calls _storage.Seek(0, SeekOrigin.Begin)
• This ensures the file stream is positioned at the start for each request when the HttpRequest is reused

🤖 Prompt for AI agents

Fix the stream disposal issue that prevents HTTPRequest reuse by modifying
stream lifecycle management.

In `SetRequestBody()` method in HttpConnectionContext.cs:
- Remove the outer `using(stream)` block that disposes the request body stream
- Keep the inner `using(var requestStream = webRequest.GetRequestStream())`
block intact
- Allow the IHttpRequestBody object to manage its own stream lifecycle

In `GetDataStream()` method in HttpRequestBodyFile.cs:
- Add stream position reset by seeking to position 0 before returning
- Match the pattern used in HttpRequestBodyBinary.GetDataStream()
- Ensure the file stream starts at the beginning for each reuse

Phase 2: Document Interface Contract and Lifecycle

This phase clarifies the ownership model and stream lifecycle expectations to prevent future similar issues.

Task 1: Document IHttpRequestBody Interface Contract

Add XML documentation to the IHttpRequestBody interface clarifying stream ownership

• Add XML documentation comments to the GetDataStream() method in src/OneScript.StandardLibrary/Http/HttpRequestBody.cs
• Document that GetDataStream() returns a borrowed reference to an internally managed stream that should not be disposed by callers
• Document that the IHttpRequestBody object owns the stream lifecycle and will dispose it when the body object is disposed
• Note that the stream position is reset to 0 on each call to support multiple reads

Task 2: Add Code Comments for Stream Handling

Document the stream handling approach in SetRequestBody to guide future maintenance

• Add comment in src/OneScript.StandardLibrary/Http/HttpConnectionContext.cs above the stream copying logic explaining that the stream is borrowed from IHttpRequestBody and should not be disposed
• Note that the stream is copied rather than passed directly to preserve the original data for potential request reuse

🤖 Prompt for AI agents

Add documentation to clarify stream ownership and lifecycle management patterns.

For IHttpRequestBody interface in HttpRequestBody.cs:
- Add XML documentation to `GetDataStream()` method
- Specify that returned stream is a borrowed reference and should not be
disposed by callers
- Document that IHttpRequestBody owns the stream and handles disposal
- Note that stream position is reset to 0 on each call for multiple reads

For SetRequestBody in HttpConnectionContext.cs:
- Add inline comments above stream copying logic
- Explain that the stream is borrowed from IHttpRequestBody and must not be
disposed
- Note that copying preserves original data for request reuse

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Fix the stream disposal issue that prevents HTTPRequest reuse by modifying
stream lifecycle management.

In `SetRequestBody()` method in HttpConnectionContext.cs:
- Remove the outer `using(stream)` block that disposes the request body stream
- Keep the inner `using(var requestStream = webRequest.GetRequestStream())`
block intact
- Allow the IHttpRequestBody object to manage its own stream lifecycle

In `GetDataStream()` method in HttpRequestBodyFile.cs:
- Add stream position reset by seeking to position 0 before returning
- Match the pattern used in HttpRequestBodyBinary.GetDataStream()
- Ensure the file stream starts at the beginning for each reuse
===============================================================================

Task: 2

Add documentation to clarify stream ownership and lifecycle management patterns.

For IHttpRequestBody interface in HttpRequestBody.cs:
- Add XML documentation to `GetDataStream()` method
- Specify that returned stream is a borrowed reference and should not be
disposed by callers
- Document that IHttpRequestBody owns the stream and handles disposal
- Note that stream position is reset to 0 on each call for multiple reads

For SetRequestBody in HttpConnectionContext.cs:
- Add inline comments above stream copying logic
- Explain that the stream is borrowed from IHttpRequestBody and must not be
disposed
- Note that copying preserves original data for request reuse

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!