I have quite a few REST end-points that process a request and simply return 200. I noticed it is an error to map the result with json(). If I try not to do any sort of mapping whatsoever, I see a browser warning that it could not parse XML. As returning nothing is pretty common, I am curious how I should be handling the response.
Here is a basic code example:
await this.http.put("/api/some_url", data).toPromise();
Here is the warning that shows up in Firefox:
XML Parsing Error: no root element found Location: http://localhost/api/some_url Line Number 1, Column 1:
If I try to map with json(), it blows up entirely. If I do nothing or try to map to text(), I just get the warning.
In all cases, the response headers contain Content-Length: 0, so I am surprised Angular2/Firefox is trying to parse anything. I don't know if this warning is coming from Angular2 or Firefox. I have tried this in Chrome and IE and there is no warning. So I am wondering if it is specific to Firefox.
When no content is returned, e.g. return Ok() (HTTP status code 200) in ASP.NET Core, content-type is (naturally) not specified, but Firefox assumes the response to be XML and tries to parse an empty document, which results in the following console error:
XML Parsing Error: no root element found Location ...
Specifying return NoContent(); (HTTP status code 204) makes Firefox happy (and also works for other browsers).
The issue is reported at Bugzilla#Mozilla:
and a parsing failure will simply be logged to the web console instead.
Related
After upgrading my Next.js, I got this message:
warn - Invalid next.config.js options detected:
- The value at .experimental has an unexpected property, allowMiddlewareResponseBody, which is not in the list of allowed properties
I know I can remove allowMiddlewareResponseBody and the warning goes away.
But I don't know if it's safe or not. I'm using my middleware to redirect user based on some data. And for response code 410, we have to return an HTML body directly from middleware.
Is it safe to remove this? If I remove it, would my middleware still work?
Working example: https://api.linkedin.com/v2/organizations?q=vanityName&vanityName=apple
Basically this is working for any other company, except if it has a & in the name, for example:
cannot use this vanity name (doesn't seem to be a url encode problem on the client side):
johnson-&-johnson or johnson-%26-johnson
The error is always the same:
serviceCode: 100
status: 403
message: Unpermitted fields present in PARAMETER: Data Processing Exception while processing fields [/-johnson]
This is not a permission problem, its working with any other vanity name.
In the response the uri seems to be messed up: https://api.linkedin.com/v2/organizations?-johnson=&q=vanityName&vanityName=johnson-
It should equal the request which is https://api.linkedin.com/v2/organizations?q=vanityName&vanityName=johnson-%26-johnson.
Also documentation doesn't seem to mention this use case.
Some other examples that work
https://api.linkedin.com/v2/organizations?q=vanityName&vanityName=johnson-controls-middle-east-africa
https://api.linkedin.com/v2/organizations?q=vanityName&vanityName=lowe's-home-improvement
How do I get the response object from call-with-input-request when the HTTP status is >= 300?
The docs say this about call-with-input-request:
Returns three values: The result of the call to reader (or #f if there is no message body in the response), the request-uri of the last request and the response object. If the response code is not in the 200 class, it will raise a condition of type (exn http client-error), (exn http server-error) or (exn http unexpected-server-response), depending on the response code. This includes 404 not found (which is a client-error).
This means that call-with-input-request signals a non-continuable condition, which (as far as I understand) means that the function does not return, and I cannot get access to the response object that would otherwise be returned. Therefore I don't see how I can actually get access to the response object corresponding to this request.
I still want to be able to inspect the response, even if its status is in the 30x-50x range. For example, I want to be able to print the HTTP reason string, or log it for debugging later. How can I achieve this?
If you trigger the exception from the REPL, you can inspect it with the ,exn comma-command. Then you'll notice the condition has a response property which is a contains the status code, headers etc.
The docs could be improved in this regard I'm sure. Perhaps you have a suggestion where to put this? The problem is that the exact contents of the condition object depend on where the condition was thrown, so not all properties will always be available.
I'm processing M365 mailbox messages via MS Graph. I'm using .Net5 and the latest version of MSGraph SDK for .NET; (particularly the PageIterator for processing email messages) - but i'm actually experiencing the issue even via a pure call via Postman: in some cases the response is just truncated abnormally (hence the response JSON could not be parsed).
One example: ~56k messages are processed successfully, then during trying to get a next page by the iterator (for me seemengly randomly; some mailbox around 56k some at 78k, but almost always 50k+) i got a JSON parsing exception (sometimes unclosed string, sometimes unexpected char).
If i take the actual next page link from the iterator while catching the exception, i can reproduce the issue in Postman; the response is truncated.
In case i query the single message that is truncated separatelly via its id then the full message is available in the response.
An example call which fails has the response payload JSON truncated (but the call actually succeeds with HTTP 200):
https://graph.microsoft.com/v1.0/me/messages?$orderby=receivedDateTime+ASC&$select=ToRecipients,CcRecipients,Subject,From,Body,HasAttachments,ReceivedDateTime&$expand=attachments($select=name)&$top=32&$skip=57454
The end of the result json:
"#odata.etag": "someetaghere",
"id": "someiidhere",
"receivedDateTime": "2017-03-19T09:15:42Z",
"hasAttachments": false,
"subject": "Fwd: Contrat Morval",
"body": {
"contentType": "text",
"content":"Some text just an example which ends somewhere in the middle of the text
Some UPDATES for this particular case:
In Postman
if i remove the "Body" param from the $select list of the above query, it constantly fails with "503 Service Unavailable" after long (<~20sec) response times
unless if i set the $top param to 31 or lower, then everything works OK, regardless if "Body" is iuncluded in the $Select list or not
if i use $top>31 with "Body" inlcuded, the response payload is truncated always at the same position of the 24th item in the result array, regardless of the value of $top
I hoped if i use 30 as page size running my Graph SDK code then i could forget this bug :), but unfortunatelly there i receive "503 Service Unavailable" for the same query that succeeds in Postman, with message
Code: generalException
Message: Unexpected exception returned from the service.
ClientRequestId: 610103aa-ac07-4b8b-b7af-0aa7bdbcce0e
The Timestamp form the response headers: Thu, 03 Dec 2020 10:49:36 GMT
Any help would be appreciated, how could i ensure that the message is loaded correctly? I tought about some throttling, quota/message size limit or restriction, but i could not find anything - and now I can reproduce the issue in postman anytime.
Thanks
My web application uses chunked encoding. I'd like to have the behavior where if any chunk generates an error, I can properly set the error code and redirect to an error page using that. Right now it seems like that can only happen if the error occurs during the first chunk because the response headers must be sent in the first chunk. Is there any way to make this work or get the behavior that I want? Thanks.
The HTTP spec allows you to provide additional headers as a "trailer" after your last chunk, which should be treated just like headers at the top of the response:
https://www.rfc-editor.org/rfc/rfc2616#section-3.6.1
Here's an example:
http://www.jmarshall.com/easy/http/#http1.1c2