All ok except for Content-Type: application/json

[hoppie305]

I've built a HTTP server and everything is fine. I can serve any Content-Type I want and everything works perfectly. I can serve JSON as long as I set Content-Type: text/plain, or text/json, or whatever.

However as soon as I set the (correct) Content-Type: application/json header, the service is still fine but Mongoose internally generates the following error -- and always the same byte lengths, no matter what I request or respond.

111b6e89 1 mongoose.c:2366:http_cb      HTTP parse, 1894 bytes
0000   16 03 01 07 61 01 00 07 5d 03 03 3e b9 63 c0 91   ....a...]..>.c..
111b6ee1 1 mongoose.c:2366:http_cb      HTTP parse, 661 bytes
0000   16 03 01 02 90 01 00 02 8c 03 03 25 3e ff 47 a5   ...........%>.G.

My typical response code:

static void respond(struct mg_connection *c,
                    struct mg_http_message *hm) {
  (void)hm; // suppress unused warning
  mg_http_reply(c, 200, "Content-Type: application/json\r\n",
    "{\"status\": true, \"message\": \"it worked!\"}\n"
  );
}

I only need to change json in for example jso and the server-side error goes away.
The error appears after the request gets actually served, I think. It is generated inside the callback function when a certain length turns negative.

What do I miss?

Hoppie

[scaprile]

What is that ? Where is that ? How do you call that ? Where do you call that ? Who is the server ? Who is the client ? Where is Mongoose ? What version ? What platform ?

Please sniff your network (using Wireshark, for example) and observe the traffic. If you can, that would be great
Please send the minimum piece of code that can reproduce the issue

[scaprile]

Please see our documentation, and follow the guidelines in our tutorials.

[hoppie305]

It's almost literally the code from the tutorials. By now I figured out what went wrong -- as I expected, I missed something.

I tested the JSON returns using a flat web browser and typing the URL. I did not use any parameters, I just took this tutorial snippet:
mg_http_reply(c, 200, "Content-Type: text/plain\r\n", "Hello, %s\n", "world");
which worked fine, and then replaced text/plain by application/json and that generated what looked like server-side complaints. This I did not expect, as the server should not be interested in what it serves, right?

After scratching my head (I never assumed this was a Mongoose problem) I realized that the web browser (Firefox) never asked for JSON and probably just squeezed the favicon request right through the same request pipe. Although I still don't really understand what goes wrong here, not using FF for the JSON request but instead a flat curl did indeed no longer turn up the Mongoose complaints.

I would love to understand the problem, but at least I now can avoid it.

If somebody can offer the explanation, yes please. Otherwise I will close this issue in two days.

Hoppie

[scaprile]

I'd give you a long explanation, but I can't, as you didn't answer my questions and I don't have the whole picture of what is going on.
Reverse-engineering your posts,

• I guess what you call "server side error" is that hex dump you posted.
  • Hopefully, the line number coincides with HEAD so I can find the source code you seem to be using
  • That piece of code is triggered when parsing of an HTTP request fails.
    • That means that "someone" is sending "something" that we can't process. Since you don't provide a Wireshark capture, I can't guess what it is. That doesn't look like HTTP and I can't guess what it is from the hex dump. If that is you using FF, then FF is pipelining something after the first request, and that is not an HTTP request.
    • The browser sends a request, Mongoose returns application/json, then the above happens
• A favicon request or similar wouldn't be related if you properly filtered URLs, thing I don't know because you say "a tutorial" and there are literally dozens of tutorials.
  • If you don't, and for some reason that is what is happening, then you would be responding with application/json to a request for an image, and I don't have a clue on what FF might decide to do next. The same would happen with text responses, though, I guess.

Again, if you send a Wireshark capture, I'll happily analyze it, but please point me to the code you are using so I don't have to guess.

[hoppie305]

Got it nailed. Two files attached:

1. Source for replication, instructions inside.
2. Wireshark capture to show that it is Firefox, not Mongoose, that causes Mongoose to sneeze.

Firefox attempts to upgrade the connection to TLS after the correct response to the request is received.
Issue basically solved, but likely to pop up again with somebody else as it is not trivial what's going on.

replicate-2968.zip

[scaprile]

Well, I can't agree and blame it on Firefox so quickly. Yes, I relieved Mongoose from any charges right from the start,
Your Wireshark capture is one-sided, there's only FF requests, I can't see Mongoose responses.
Your source is TL;DR, I've already read that here. I managed to get to the code and I see you are responding with a 500 code to something that requires a 400 response, 404 to be precise. I don't see that being exercised, though, as I don't see any of the Mongoose responses in that capture file
FF is not upgrading the connection, it is closing it and trying a new one using TLS. Two attempts. Why ? I would justify that if you requested a non-existent URL, since you just told it that the requested resource is temporarily unavailable because of some issue with yourself (the server), instead of a plain "not found" (404). However, if the requested URL was correct, and the response was 200 and the proper contents (thing I don't see because you didn't capture that), then yes, this is weird.

We can close this if you agree
Regards.

[hoppie305]

As the sources are 100% the README.md file except for the application/json addition, and I did request the proper URL which was answered correctly (apologies for not recording that), the only response given (and correctly received by FF) was the 200. I agree that FF closed and reopened the connection. It then most likely requested the favicon over TLS, which failed.

As we are now mostly trying to reconstruct the way FF handles JSON returns, which is not very relevant, I propose to leave it at this.