I happily used PhpStorm and MantisBT together for months, but now I'm facing a strange problem.
Trying to establish a connection to my mantis instance (self hosted), I get the error:
Request failed. Reason: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Content is not allowed in prolog.
While I understand, what this error message means, I can't tell why it happens and I can't control the response I get from Mantis.
I neither found answers at the PhpStorm docs nor at Google nor at the Mantis bug tracker itself.
So I want to try my luck here. Is anyone else experiencing this or could give some advice?
Thanks to #user10550971 comment, I found the issue. The link to check if SOAP is enabled or not mentioned, that the PHP Soap extension was missing.
Although I would have sworn, that I didn't make any changes at server side, I did.
I updated my PHP version and forgot to install SOAP.
Related
Latest Chrome update breaks WASM backend when using Tensorflow.js. Apparently, browser enforces more strict Content-Security-Policy headers now.
Gist of the error (from console):
"Initialization of backend wasm failed"
"Error: Failed to construct 'Worker': Access to the script at 'blob:https://fiddle.jshell.net/c95fbade-77fe-4945-a4dc-25a3a19f97d6' is denied by the document's Content Security Policy.
Curious if anyone figured out a way to run it?
Browser/OS - Chrome 91.0.4472.77 / macOS Big Sur 11.3.1
To check out error go here - https://jsfiddle.net/alex_oliynyk/2b6oa4dm/14/
Cheers!
My question got answered in the Tensorflow.js repo. I'll repost the solution here in case anyone has the same issue.
CSP headers to help:
'Cross-Origin-Embedder-Policy': 'require-corp',
'Cross-Origin-Opener-Policy': 'same-origin',
Still, after figuring out CSP headers Tensorflow.js did not work. Threw an error connected to SIMD.
This appears to fix it for the time being:
tf.ENV.set('WASM_HAS_SIMD_SUPPORT', false);
tf.ENV.set('WASM_HAS_MULTITHREAD_SUPPORT', false);
It disables SIMD support and cuts performance, thus I hope it will be fully addressed in the future versions of the lib.
Cheers,
As the title suggests, I'm receiving this error when trying to make a simple POST request via a THTTPClient in Delphi and the connection isn't completed so I get no response:
lHttpResp := FHTTP.Post(
'https://url123/',
jsonToSend,
nil,
[
TNetHeader.Create('content-type', 'application/json;charset=utf8'),
TNetHeader.Create('accept', 'application/json;charset=utf8')
]);
This call works without an issue when built with Delphi 10.3.2 / Windows 10.
I thought perhaps copying the 10.3.2 \Embarcadero\Studio\20.0\source\rtl files to the 10.3.1 machine might have done the trick, alas it didn't.
Upgrade is an option, however it would be nice if there was a simple code fix/work around for 10.3.1.
Edit: I thought this might help, however it didn't: Unspecified certificate from client when using TRESTRequest
How do I get this working in 10.3.1?
The solution is to just upgrade to a version >= 10.3.2
Problem
The JSON is returned correctly encoded but json_last_error equates to 5 thus Laravel throws this exception on response creation in JsonResponse->setData().
Related References
A resolved bug report for symfony and PHP 7.3: https://github.com/symfony/symfony/issues/31447 mentions this exact issue. That is:
If a json_encode()/json_decode() without JSON_THROW_ON_ERROR encoding option set throws an error, any subsequent call to the same with that flag set will not reset the error of the previous call.
The JSON_THROW_ON_ERROR RFC mentions this behavior as by design: https://wiki.php.net/rfc/json_throw_on_error
Unfortunately Laravel's code uses the flag but does not cater for this behavior and throws exception if json_last_error() returns a non zero value. Which in this case should have been ignored as it will always reference the previous error. Perhaps a version check should be added.
Investigation
I have also searched the bowls of my application and haven't found the misbehaving json_encode/json_decode without JSON_THROW_ON_ERROR set so I am sure it is internal to Laravel before Middleware calls.
Additional Context
This suddenly started happening today in our server. It happens when users connect to the server through the web app from select systems. Even though system kind should not affect server side response generation but still web app always generates this error for specific PCs/Mobiles.
Proposed Hack
After sifting through the Symfony bug report, the easiest workaround I have found is to just clear the error through an inconsequential json_encode('1') call. Which effectively resets the error code to 0 and the later JSON methods work fine.
Fortunately we have our own response generation class so just adding this before the hand-off to Laravel works fine.
Still this is a hack. I am more interested in a better solution or any bug fix available.
I have a problem with GF4 while calling a web service I coded using http post. GF4 responds with a "Post too large" error. My post data is about 3MB.
Here is the GF4 debug log:
WARNING: Post too large
WARNING: StandardWrapperValve[obx2oex]: Servlet.service() for servlet obx2oex threw exception
java.lang.IllegalStateException: Post too large
at org.glassfish.grizzly.http.server.Request.parseRequestParameters(Request.java:2024)
at org.glassfish.grizzly.http.server.Request.getParameter(Request.java:1052)
at org.apache.catalina.connector.Request.getParameter(Request.java:1547)
at org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:448)
...
I already googled for this issue and found some help that encourages to modify the server configuration. I edited the following part in the domain.xml:
<http-service>
<access-log></access-log>
<virtual-server id="server" network-listeners="http-listener-1,http-listener-2"></virtual-server>
<virtual-server id="__asadmin" network-listeners="admin-listener"></virtual-server>
<property name="maxPostSize" value="2097152"></property>
</http-service>
and restarted the server. But the error still occurs.
Does anybody know, how to solve this "post too large" issue?
Thanks for your help!
PS: I just saw the starting log of the GF4 and it told me:
WARNING: Unsupported http-service property maxPostSize is being ignored
So where should I tell GF4 to accept large post data?
Open Glass Fish administrative console, select
Configurations - server config - Network Config - Network Listeners
- http-listener-1
and
tab HTTP.
There is parameter Max Post Size. Increase it as you wish.
Look screenshot
My first attempt coding my webservice was a servlet that accepts data via POST parameter of HTTP. That lead to the "Post too large" error, when sending more than 2MB.
I got a suggestions to code it as REST service. It is very strange, but now it works with more than 2MB. Even while the data is sent via http post.
Maybe it should help someone.
But nevertheless I'd like to know, where you can set the maxPostSize value in GF4 server.
My site was valid until today, wondering wether it is my site's or the validator's fault.
I am getting this message:
The error encountered was: 500 Can't connect to localhost:8888 (connect: Connection refused)
HTTP Error 500 is an Internal Server Error, so that will be their fault. Try validator.nu whilst you are waiting.
W3C validator maintainer here. Tip: Next time you see that message, try validating your document directly at http://validator.w3.org/nu/ instead.
Because if you see that 500 error it means the validator is trying to reach the HTML5 backend, which runs as a separate service/process responding at localhost:8888 on the validator host.
But we actually run several validator hosts, round-robin, so if you see that 500 error it could mean that only one of the HTML5 backends on one of the hosts is temporarily down. And if you go to http://validator.w3.org/nu/ you might get lucky and hit a different host and it'll work.
On the other hand if you get a 404 from http://validator.w3.org/nu/
it most likely means you caught me in the middle of restarting/redeploying the W3C HTML5 validator backends to pull in changes I've made to the sources from https://github.com/validator/validator
But that never takes me more than a few minutes, so on your end you should never be seeing that 500 error for more than, say, 10 minutes at most. So if/when you do see it for any longer than that, please report it either by tweeting to #w3c or #sideshowbarker on twitter, or pinging me on IRC (MikeSmith on #whatwg or #w3c on irc.freenode.net).
I think it's pretty clear from the error that it's a problem at their end:
Checking the Document Type of this document requires the help of an external tool which was either not enabled in this validator, or is currently unavailable. Check in the validator's system configuration that HTML5 Validator is enabled and functional.
The error encountered was: 500 Can't connect to localhost:8888 (connect: Connection refused)
(My emphasis.) I expect they'll get it fixed Right Quick Like.
We were getting the following error while checking the domain in W3C validator and we managed to fix it by installing CA Bundle and Intermediate Root certificates for the same domain. Now, the domain is able to pass through the W3C validation check and reporting appropriate result.
===================================
Sorry! This document cannot be checked.
Error
I got the following unexpected response when trying to retrieve <https://our-xx-domain.in/>:
500 Can't connect to our-xx-domain.in:443
If you made recent changes to your domain name (DNS) configuration, you may also want to check that your domain records are correct, or ask your hosting company to do so.
===================================