GCDWebServerIsValidByteRange is wrong #317
Comments
It's intentional, it's not to be interpreted as a regular See
|
But it does not work, what is the syntax to say you want the entire file. |
What I mean is this is used in the GCDWebServerFileResponse in Swift the Range is not optional so you have to reimplement the logic that is already on ObjC to find the file length. hasByteRange always return true even if you pass a Range(0,-1)
|
This in turns matches the way the "Range" HTTP header is parsed: That said I'm not sure why you're trying to achieve. Either you want to return a range of the file, and use the range arg, or you want the entire file and pass a |
This is the code: I need to use the full constructor to pass the mime type |
Then just pass (NSUIntegerMax, 0)? |
I am in swift I tried to pass (Int.max, -1) but it does not work. |
This make the API very obscure anyway |
I still don't understand why you say that GCDWebServerIsValidByteRange implementation is correct. The Range is valid if the location is not NSUIntegerMax AND the length is more than zero. This is not what the code says. I am just asking for the correction of the OR to AND. |
Per the docs:
Simple boolean logic 😄 |
Hold on the documentation you are referring to is for the request not for the response, and because the documentation say so it does not means it is right, a range of (0,0) is invalid as the length is 0. and certainly one that is (0,-1) is also invalid. The pb is that is used at two places for different reasons. It check that the range in the request is valid and you may be right, and it checks that the range in the params of the response constructor is valid. In the second case it is used to detect if the client (the developer) has supplied a range. I am not interested in fixing the behaviour in the request case but in the response. This can be done in either of 2 ways. by fixing the implementation of the check or better by making the range optional and providing a default value. so that we don't need to pass an invalid range which does not make for a good API anyway. |
The doc for response is consistent with doc for request and is also very clear:
So just pass |
The following code is wrong I suppose the intent was to put an &&
The text was updated successfully, but these errors were encountered: