What's the expected "GET chunked blob" when the uploaded content is empty

[wxiaoguang]

Spec says:

A chunked blob upload is accomplished in three phases:
  1. Obtain a session ID (upload URL) (POST)
      * Content-Length: 0
  2. Upload the chunks (PATCH)
  3. Close the session (PUT)

And

To get the current status after a 416 error, issue a GET request to a URL <location>
MUST have the following headers:
  Location: <location>
  Range: 0-<end-of-range>

What's the expected response for the "GET" request if it is called immediately after "1. Obtain a session ID (upload URL) (POST)"? Now the content is empty, size is 0, but we can't respond "0--1" here.

Should we define this behavior as 400 or some other error codes? Or leave it as the undefined behavior (responding anything is fine)?

[sudo-bmitch]

I'm guessing few ever see this because the 416 would be triggered after at least one request was at least partially successful (otherwise the original upload URL should work and no other location URLs would have been seen). For the desired behavior in this edge condition, we should look at both the upstream HTTP RFCs and existing registry implementations. Others are welcome to check, or I'll dig into it when time permits.

[wxiaoguang]

Agree, I guess no one would really see this because it is just an edge case.

While I think it's good to clarify the behavior because when I was writing the server-side code, I just found that it's not clear about how to correctly respond 😄

handle(GET ... ) {
    if size > 0 {
       Location: <location>
       Range: 0-<end-of-range>
    } else {
       // then ..... a dangling else branch?
    }
}

[XenoAmess]

meet same problem here.

[XenoAmess]

Agree, I guess no one would really see this because it is just an edge case.

While I think it's good to clarify the behavior because when I was writing the server-side code, I just found that it's not clear about how to correctly respond 😄

handle(GET ... ) {
    if size > 0 {
       Location: <location>
       Range: 0-<end-of-range>
    } else {
       // then ..... a dangling else branch?
    }
}

that is why when we define range(in other repo/schema), we would usually let it left inclusive and right exclusive...
though well, go people made the spec as it be, and it be an old spec hard to change,
so maybe the only way (to fix it, if needed) is to allow 0--1, means 0 to -1, thus no any bytes...
(I know it looks weird, but still better solution than change the meaning of the end-of-range and let every client&server&checker do a rewrite...)

[sudo-bmitch]

that is why when we define range, we would usually let it left inclusive and right exclusive...
though well, go people made the spec as it be, and it be an old spec hard to change,

Who is "we", and why is this related to Go? From RFC7233:

The first-byte-pos value in a byte-range-spec gives the byte-offset of the first byte in a range. The last-byte-pos value gives the byte-offset of the last byte in the range; that is, the byte positions specified are inclusive.

https://datatracker.ietf.org/doc/html/rfc7233

[XenoAmess]

good news is most impl of clients would just retry when the first block errors.(well at least docker would)
so, if the upload error occur when the first chunk upload, even just let it error 500 and the client would still retry itself.....
if the upload error occur after the first chunk, the cannot be 0...
(well actually I suggest you provide OCI-Chunk-Min-Length because I don't know if there be client impl who be crazy enough to pinning 0-size chunks (as I didn't see there be doc to say it illegal)...but just most client impls would make first chunk with some data...)

[XenoAmess]

From RFC7233:

The first-byte-pos value in a byte-range-spec gives the byte-offset of the first byte in a range. The last-byte-pos value gives the byte-offset of the last byte in the range; that is, the byte positions specified are inclusive.

https://datatracker.ietf.org/doc/html/rfc7233

A strong rebuttal!

why is this related to Go?

I checked it

package main

import (
	"fmt"
)

func main() {
	a := []int{1, 2, 3, 4, 5}
	b := a[2:3]
	fmt.Println(b)
}

it returns [3]. so yes, go is clean and out of this.
I must admit, I do have a bias against the Go language.

Who is "we"

slicing functions