POST with emtpy Body

[predic8]

A POST without a body causes Membrane to wait on that thread.

RFC Reference (short)

• RFC 9112 (HTTP/1.1 Semantics) allows POST without body.
• A sender should send a Content-Length or Transfer-Encoding only if a body exists.
• Absence of either simply means: empty body.

Change:
If there is no Content-Length and no Transfer-Encoding => Do not wait but Forward

Cases:

POST /foo
Content-Type: application/json

=> Request with empty body => Forward

POST /
Content-Length: 5

hello

=> Forward

[predic8]

@coderabbitai Review requirements and optimize

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch the details of issue #2395 to understand the full context
gh issue view 2395 --json title,body,comments --jq '{title: .title, body: .body, comments: [.comments[].body]}'

Length of output: 665

---

@predic8 I've reviewed the requirements for issue #2395. Here's my analysis and optimization suggestions:

✅ Current Requirements Analysis

The requirements are well-structured and address the core issue. The RFC 9112 reference is correct - POST requests without bodies are valid.

🎯 Optimization Suggestions

1. Add RFC Section Reference

Be more specific about the RFC section:

• RFC 9112, Section 6 (Message Body Length) defines the algorithm for determining message body length
• The absence of both Content-Length and Transfer-Encoding means a zero-length body (for requests)

2. Clarify Expected Behavior

Add to requirements:

Current Behavior: 
- Membrane waits indefinitely (or until timeout) for body data
- Blocks the processing thread

Expected Behavior:
- Immediately treat as empty body and forward request
- No blocking/waiting on the thread

3. Expand Test Cases

Add these edge cases:

# Case 3: POST with Transfer-Encoding: chunked
POST /foo
Transfer-Encoding: chunked

0\r\n\r\n

=> Empty chunked body => Forward

# Case 4: POST with Content-Length: 0
POST /foo
Content-Length: 0

=> Explicit empty body => Forward

# Case 5: HTTP/1.0 without Content-Length
POST /foo HTTP/1.0

=> HTTP/1.0 empty body => Forward

# Case 6: POST with Expect: 100-continue but no content
POST /foo
Expect: 100-continue

=> Handle appropriately (respond with 100 Continue, then expect body or proceed)

4. Security Consideration

Add note:

Security: Ensure fix doesn't introduce request smuggling vulnerabilities 
when proxying between HTTP/1.0 and HTTP/1.1 backends.

5. Negative Test Cases

Include scenarios that should still wait:

# Should WAIT: Content-Length present
POST /foo
Content-Length: 100

=> Should wait for 100 bytes

# Should WAIT: Transfer-Encoding present
POST /foo
Transfer-Encoding: chunked

=> Should wait for chunked body

6. Implementation Note

Consider adding:

Implementation: Apply this logic to all HTTP methods that can have bodies 
(POST, PUT, PATCH, DELETE), not just POST.

📋 Optimized Requirements Summary

Problem: POST requests without Content-Length or Transfer-Encoding headers cause Membrane to block indefinitely waiting for a body.

Root Cause: RFC 9112 §6 states that absence of both headers indicates a zero-length body for requests, but Membrane's current implementation waits for data.

Solution: When a request has neither Content-Length nor Transfer-Encoding header, treat it as having an empty body and forward immediately without waiting.

Scope: All HTTP methods that support request bodies (POST, PUT, PATCH, DELETE).

Edge Cases to Handle:

• Explicit Content-Length: 0
• Empty chunked encoding (0\r\n\r\n)
• HTTP/1.0 requests without Content-Length
• Expect: 100-continue header interaction

Would you like me to create more detailed test scenarios or help with implementation guidance?

[predic8]

• Testcases from 3.X might already be implemented
• Same behaviour for PUT is desired