no content returned anymore when POSTING to salesorder

[Trygve Storrønningen1]

It seems after the latest update, no content are returned when we POST to salesorder.
This is both on v1 and v2

When order is successfully POSTed, we get 201, and headers - but no content.

Can you confirm this change?

Is it intentional ... if so, why?

IMHO, this is not restful;
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201
The HTTP 201 Created success status response code indicates that the request has succeeded and has led to the creation of a resource. The new resource is effectively created before this response is sent back and the new resource is returned in the body of the message, its location being either the URL of the request, or the content of the Location header.

[Trygve Storrønningen1]

We did a rewrite to check Content-Length after this header was added after the infrastructure change on February 20th.

Most POSTed orders are now 201 - and we again read ordrenumber from Location 🙂

But only most orders. The orders which are failing are missing header Content-Length, and they have header Transfer-Encoding in addtition. Is this because of infrastructure in AWS or in the API - and is it a lack of consequense we have to live with?

[Trygve Storrønningen1]

---

The orders which are failing are missing header Content-Length, and they have header Transfer-Encoding in addtition. Is this because of infrastructure in AWS or in the API - and is it a lack of consequense we have to live with?

---

Still orders are failing from time to time -- and in those cases the response header Content-Lenght is missing, and Transfer-Encoding is appearing.  Is this because of infrastructure in AWS or in the API - and is it a lack of consequense we have to live with?

[Magnus Johnsen]

Hi,

We are checking this internally, in the case where the operations are failing, we can confirm that this seems to be happening, no content-length is provided, and transfer-encoding is provided.

When the operation succeds the opposite is true. 

[Trygve Storrønningen1]

Magnus wrote:

> The only time we repond with a body is to return error messages or warnings. 

It seems according to RFC 2616 there should be a body as well:
If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30 ).

This is from section 9.5, paragraph 4; https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

[Trygve Storrønningen1]

Magnus, you write nothing was changed on 16.02 -- I believe -- but this change which makes problems now was on Saturday 20.02

Could it be something done in infrastructure now chopping off empty response bodies totally?

Maybe it was returned {} before ? And something in infrastructure is trimming this?

[Magnus Johnsen]

We are checking if this might be the case and waiting for replies. 

[Magnus Johnsen · Accepted solution]

Hi,

Do we have checked some responses we have share for earlier cases and in those there were no content bodies either.

The update was in regards of an Apache proxy we use, and we tested bypassing it. What has changed since is that there are now two headers added to the response:

Server: Apache/2.4.25 (Debian)

Content-Length: 0

Our guess is that it is the content length header that triggers an issue in the method you are using.

There is nothing else we can see that is different. 

[Trygve Storrønningen1 · Accepted solution]

Two new headers. In other words, a change in the response from your server.

[Trygve Storrønningen1]

But, something changed on Saturday evening, we changed nothing, and Visma changed something

Maybe something done different now by AWS?

This code runned as it should before this time on Saturday:

1 responseHeaderFields = connection.getHeaderFields()

2 InputStream stream = (InputStream) connection.content

Now we get header fields in line 1 here, but line 2 crashes as there is no content.

connection is HttpsURLConnection

So before this time on Saturday, this code ran well, after this time it crashes.

Why?

[Anonymous]

Hi Trygve,

In the second line of your code you are doing an unsafe object casting. It means that you are casting to an object type InputStream, but without checking that your object is of type InputStream . It will give you a runtime error in case your object is not of the type InputSteam.

You can read more about it in this article:

https://docs.microsoft.com/en-us/dotnet/csharp/how-to/safely-cast-using-pattern-matching-is-and-as-o... 

It might not help you with your problem, but since you pasted this code I thought it could be a good advice.

BR,

Rolf Henrik

[Trygve Storrønningen1]

True, RFC 2616, 4.2 says so (https://tools.ietf.org/html/rfc2616#section-4.2)

But RFC 7231, 7.1.2  (https://tools.ietf.org/html/rfc7231#section-7.1.2) which defines Location says nothing about case it seems, but all the way they reffer to Location and not to location.

Anyway further debugging shows now capitalized Location, as Magnus says.

It might be I have been fooled by swagger or Fiddler here

[Trygve Storrønningen1]

Ok, thank you for clearification 🙂

But it seems definitely something changed after Saturday 21:51 -- this was the time of the last order where we successfully read the created ordernumber from Location header after 201

3 hours and 20 minutes later; after this time all orders exported fails, and it seems because we now cannot read the created order number in the header anymore.

It seems after that time we get

  location

with lowercase: 

location: https://integration.visma.net/API/controller/api/v2/salesorder/000034 

Earlier we got correct RFC-standard and as-in-swagger:

Location: https://integration.visma.net/API/controller/api/v1/salesorder/000035

[adrianm · Accepted solution]

Headers are case insensitive: RFC 2616, 4.2

>Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

(And I have heard AWS sometimes rewrites headers in a different case)

[Magnus Johnsen]

There was an infrastructure maintenance on Saturday. When testing, I am receiving capitalized Location, are you still having the same issue?

[Magnus Johnsen]

Hi,

Nothing was changed in the last update for salesOrder: [Release Notes] - Visma.Net API 8.37.0 - 16.02.2021

The same as with other endpoints, no body is returned but the location of the request is always in the location header.

This is also shown in swagger:

The only time we repond with a body is to return error messages or warnings.