Exotic characters in request leads to "Missing content with timeout."-error response.

[Boerrild]

I have been playing around with a XOOM Starter generated example, not using the dispatch-feature for resources. I have a running version with a Sapper-based ui, capable of creating instances of my domain object, and modify them. However, whenever I use "non-standard" characters, like æ, ø, å or é in my request data I seem to get a "Missing content with timeout."-error response.

I reckon it has something to do with encoding and content length mismatch due to the usage of "double-byte" characters, but I've been unable to figure out the remedy. I've also noticed this behaviour in the XOOM starter app itself, when I naively tried to create an aggregate with a danish name containing the danish letter 'ø'. I wonder if this a feature or a bug? (The vlingo version was 1.5.1, btw).

Below is the excerpt of an example request that fails (produced when pushing the Generate-button on the last page of the XOOM starter UI). The only difference in this request, from one that succeeds, is that I've replaced the 'e' in 'project' with an 'æ' in the project directory path (see the "projectDirectory" path below).

(copied from chromes DevTools-section):

GENERAL:

Request URL: http://localhost:19090/api/generation-settings
Request Method: POST
Status Code: 400 Bad Request
Remote Address: [::1]:19090
Referrer Policy: strict-origin-when-cross-origin

REQUEST HEADERS:

Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: da,en-US;q=0.9,en;q=0.8,en-GB;q=0.7
Connection: keep-alive
Content-Length: 3250
Content-Type: application/json
dnt: 1
Host: localhost:19090
Origin: http://localhost:19090
Referer: http://localhost:19090/generation
sec-ch-ua: "Google Chrome";v="89", "Chromium";v="89", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36
{context: {groupId: "com.capfire.healthcare", artifactId: "journal", artifactVersion: "0.0.2",…},…}
context: {groupId: "com.capfire.healthcare", artifactId: "journal", artifactVersion: "0.0.2",…}
deployment: {clusterNodes: 3, type: "DOCKER", dockerImage: "journal-app", kubernetesImage: "", kubernetesPod: ""}
model: {,…}
projectDirectory: "/Users/boerrild/Work/learn/vlingo/xoom-start/projæct"
useAnnotations: false
useAutoDispatch: false

RESPONSE HEADERS:

Content-Length: 29

REPONSE BODY

Missing content with timeout.

Another difference from the succeeding request, is the Content-Length, which is 3249.

(Fun-fact: The danish letter 'æ' is the concatenation of 'a' and 'e' and is pronounced like the second 'e' in 'eject')

[jakzal]

I tried the latest xoom-starter and got a 400 bad request back in dev tools (the UI didn't show any errors):

URL: http://localhost:19090/api/generation-paths
Status: 400 Bad Request

[VaughnVernon]

This is an interesting issue. We've discovered that the browser indicates a Content-Length that is N bytes greater than the body content, where N is the number of extended characters included in the body. For example, we tested with all 5 of the special characters that you included along with other text in a single request, and the content total length is 46. When viewing the content with the browser's tools, the Content-Length is 51, so N is 5. Is the server supposed to accept as many bytes as are in the payload, even if it is less than the Content-Length indicates? Any insights would be helpful.

[VaughnVernon]

Fixed by vlingo/xoom-http@4e244c4

[VaughnVernon]

The problem was the difference in length of the bytes vs the characters in the decoded string, where the bytes length is used in the Content-Length header. The string is always a less length than the bytes. I was previously only counting the length of the decoded string.