rmaucher commented on PR #810:
URL: https://github.com/apache/tomcat/pull/810#issuecomment-2700562654
Made changes to try it. Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific
rmaucher closed pull request #810: Ensure partial put data range not exceed
ContentRange declared
URL: https://github.com/apache/tomcat/pull/810
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the s
rmaucher commented on PR #810:
URL: https://github.com/apache/tomcat/pull/810#issuecomment-2698217679
I'm not sure. Since this is writing to a temporary file rather than the real
resource, it is possible to back out without consequences. As a result, I think
I will implement throwing an IOE
Chenjp commented on PR #810:
URL: https://github.com/apache/tomcat/pull/810#issuecomment-2694798531
This part is semantically ambiguous, and yet undefined in RFC.
We have to make decision when edge case happen:
1. payload length is larger than content-range. (e.g. payload="01234567
rmaucher commented on PR #810:
URL: https://github.com/apache/tomcat/pull/810#issuecomment-2692889514
Surprisingly, I verified that there's no specification language on what to
do if content-length (or whatever similar like chunking) conflicts with
content-range.
--
This is an automated
Chenjp commented on PR #810:
URL: https://github.com/apache/tomcat/pull/810#issuecomment-2608927392
As expected:
```
curl -i http://localhost:1080/uploads/size-1.dat -X PUT -H "Content-Range:
Bytes 0-0/1" -d 11
```
HTTP/1.1 201 Created
```
curl -i http://localh
Chenjp opened a new pull request, #810:
URL: https://github.com/apache/tomcat/pull/810
Ensure updated content size not exceeds bounds ***(end-start+1)*** declared
by Content-Range header.
For backwards compatibility, just discard the rest part instead of a sending
400.
--
This is
