Creation With Upload - POST failed StatusCode 200

Tus
1

Hello;

Request is used to create a new upload resource. The header is the following:
POST
Tus-Resumable: 1.0.0
Upload-Length: 375
Content-Length: 0
Upload-Metadata: filename d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg==

The server response is the following:
StatusCode = 200 (OK)
Location: /upload/24e533e02ec3bc40c387f1a0e460e216

The expected result:
StatusCode = 201 (Created)
Location: /upload/24e533e02ec3bc40c387f1a0e460e216

Any ideas why the server returns 200 instead of 201?

Thank you.

NOTE: I am using the TUS.io client ‘tus-dotnet-client’.

2

That’s probably just a bug in the server. What tus server are you using?

3

Thanks for the reply.

I don’t know the server configuration. Actually I only have the URL of the EndPoint.

I show you the total response:

{System.Net.HttpWebResponse}
CharacterSet: “ISO-8859-1”
ContentEncoding: null
ContentLength: 0
ContentType: “text/plain”
Cookies: {System.Net.CookieCollection}
Headers: {Date: Wed, 13 Sep 2023 15:18:46 GMT
Connection: close
Tus-Resumable: 1.0.0
Location: /v1/contribuyente/migeigv/libros/rvierce/receptorpropuesta/web/propuesta/upload/604d5649-c08e-48bf-ba6d-863d669648c2
X-ServiceName: migeigv-libros-receptorpropuesta-web-backend
X-ServiceEnvironment: LOCAL_DEV
X-ServiceVersion: 1.4.0-5
X-ServiceInstanceId: QIcGh
Access-Control-Expose-Headers: Location, Upload-Offset
Content-Type: text/plain
Content-Length: 0

}
IsFromCache: false
IsMutuallyAuthenticated: false
LastModified: {13/09/2023 10:19:14}
Method: “POST”
ProtocolVersion: {1.1}
ResponseUri: {https://api-sire.sunat.gob.pe/v1/contribuyente/migeigv/libros/rvierce/receptorpropuesta/web/propuesta/upload}
Server: “”
StatusCode: OK
StatusDescription: “OK”
SupportsHeaders: true

Any comments, I appreciate you. Thank you.

4

If you don’t control the server, then you should raise this as a bug report to the server’s administrators. Maybe they can relay this report to the developers behind their tus servers.

Some clients accept any 2XX status code for responses, even though the spec requires a 201. The tus-dotnet-client does not seem to do this and errors out for non-201. You could try to report this to its author or to fix the bug on your own.

There is no switch in the tus protocol controlling whether a 200 or 201 is returned.