Hi everyone,
I’m sending a file to a Rest WebService, in this way:
HttpWebRequest := HttpWebRequest.Create('http://eshop.xxxxx-eu.com/ws/api/rest');
HttpWebRequest.Method := 'POST';
HttpWebRequest.ContentType('application/x-www-form-urlencoded');
postString := STRSUBSTNO('json=%1',pJson);
StreamWriter := StreamWriter.StreamWriter(HttpWebRequest.GetRequestStream);
StreamWriter.Write(postString);
StreamWriter.Close;
StreamWriter.Dispose;
HttpWebRequest.GetResponse;
But I’mn getting an error in the WebResposne, becasue the server is not responding anything. How can i “run” the request without expecting any response?
Thank you very much
And what does the error message look like?
In a situation like this, when a client does not receive any response from the server, I would look for a communication error in the first place. Either the server does not receive the request, or the client does not get the response. HttpWebRequest doesn’t support such “deaf” requests, because it’s one of the basic requirements of the HTTP protocol that the sever must send a response. It may not contain a body, but at least the header with a status code must be sent back to the client.
THnaks for your answer Alexasnder. THe issue is that I’m sure that the request is correct, because the provider tells me that they are receibing the jSOn.
The issue is that the service isn’t “prepared” to return any response, but as you’ve said, it’s a basic requirement of the HTTP protocol, so they should repair that, am I right?
And how should it be prepared to respond? I’m afraid that “not prepared” in this case means that it is non-operational. RFC on the HTTP protocol states that the server sends the response after processing the request, and the client must interpret the status code: https://tools.ietf.org/html/rfc2616#section-6
Or otherwise, how can you be sure that your request is received and processed, if you don’t receive any confirmation?
Yes, I’m sure because I can see the log of the webService, and I see that there is processing the jSon I’m sending.
The issue is that the provider has the service let’s say, “strange”. I’ll explain myself.
Basically, they are sending a response, but when the jSon is fully processed. If the jSon is small, there is no problem. But if the jSon is wrong, 2 events are happening:
1: Nav get a timeout error because we haven’t received any response yet
2: Also the webService is having an internal error.
So, the provider is trying to send a response at the moment they receive the the jSon, doesn’t matter if it is still processing it. This is the correct way to work.
I did not want to insert my 5 cents, but could you answer for yourself - if you see Log for webService WHY you can’t receive any Reason Code xxx (e.g. 401 or …) answer? If you prepare the right request, sent it and Service received it you should receive the answer.
P.S. TO be honest, I don’t understand why did you use the StreamWriter for HttpWebRequest…I plan to be at home on weekend and if you have not to find the answer, I will send my version (I did request|responce handling for NAV 2016)
Answering to your question:
1: I can see the log with the filezilla, not with NAV. That’s how I know that the platform is processing the jSon file. And I don’t receive answer in case the jSon is long, because the server is sending the answer when the jSon is fulkly processed, and NAV get a timeout.
2: I’m using the streamwritter because it was the only way I found to send the json into a variable called “json”, system requirements… Probably isn’t the best way to solve, but it works…
I’m preparing formatted JSON without this DotNet component… but I’m “out of office” now.
I’m using NAV2018, may be that will answer to a few doubts… .
Ok, so the server does respond after all, and it is the timeout on large messages that is the issue. Maybe all you need is increase timeout on the HttpWebRequest?
https://docs.microsoft.com/en-us/dotnet/api/system.net.httpwebrequest.timeout?view=netframework-4.8
Or else, use asynchronous request and response.
I’ve jsut read this message, thnak you very much, FInally, the server provider changed the webService to send a resposne, so we’ve sovled like that.