jQuery 1.9.1
The request never gets sent and seems to just error out. console.log output shows Request failed: error I do not know how to debug this further.
$.ajax({
beforeSend: function (xhr) { xhr.setRequestHeader ('Authorization', 'Token c576f0136149a2e2d9127b3901015545') },
type: "GET",
url: "https://example.com/endpoint",
dataType: "json"
}).done(function( msg ) {
console.log( msg );
}).fail(function(jqXHR, textStatus, errorThrown) {
console.log( "Request failed: " + textStatus );
console.log( errorThrown );
});
Inspecting the network traffic in google chrome shows
Method: OPTIONS
Status: (canceled)
Type: Pending
However using curl works fine:
curl https://example.com/endpoint -H 'Authorization: Token token="c576f0136149a2e2d9127b3901015545"'
Here is the jsFiddle: http://jsfiddle.net/2vtyD/1/
Note: this is not an issue with Access-Control-Allow-Origin as I have this part working.
I know I must be missing something...
Update:
Everything works fine when I switch to http. It is only when using https this problem occurs. I thought it might be because I am using a self-signed certificate (invalid). But other SSL requests (non-authorization ie not 'OPTIONS' ) work just fine. So it only seems to be a combination of SSL and OPTIONS requests. The status in chrome says canceled and from looking at the server logs apache logs shows some activity but it never makes it the rails web app.
Here is a sniplet of the apache log:
[info] [client 10.0.2.2] (70007)The timeout specified has expired: SSL input filter read failed.
[info] [client 10.0.2.2] Connection closed to child 10 with standard shutdown (server example.com:443)
[info] [client 10.0.2.2] Connection to child 11 established (server example.com:443)
[info] Seeding PRNG with 656 bytes of entropy
[info] [client 10.0.2.2] (70014)End of file found: SSL input filter read failed.
[info] [client 10.0.2.2] Connection closed to child 11 with standard shutdown (server example.com:443)
However, these types of messages are occurring for all SSL requests. So I am basically at a loss on how to proceed.
Use a valid SSL certificate.
For some reason GET, POST, PUT and DELETE requests work fine with a self signed certificate. But OPTIONS request does not. Using a valid SSL certificate everything will work fine.
Related
Brand new project. I am simply trying to access adobe.com but getting a ESOCKETTIMEDOUT error. Given this is a new project, I doubt anything is wrong with the code. I am on MACOS 12.6.1 Monterey with no firewall on. Any settings/changes I need to make?
CypressError
cy.visit() failed trying to load:
https://www.adobe.com/
We attempted to make an http request to this URL but the request failed without a response.
We received this error at the network level:
> Error: ESOCKETTIMEDOUT
Common situations why this would fail:
- you don't have internet access
- you forgot to run / boot your web server
- your web server isn't accessible
- you have weird network configuration settings on your computer
cypress/e2e/spec.cy.js:3:8
1 | describe('empty spec', () => {
2 | it('passes', () => {
> 3 | cy.visit('https://www.adobe.com')
| ^
4 | })
5 | })
It was answered here: Cypress, cy.visit() failed trying to load ESOCKETTIMEDOUT
Just add the object { headers: { "Accept-Encoding": "gzip, deflate" } } as the second argument of cy.visit (but no need to modify Cypress config file in my case)
When using Xdebug directly from VSCode using one of two PHP extension (xdebug.php-debug, devsense.phptools-vscode) for debugging everything works as expected. But I have a shared environment where an Apache/PHP/Xdebug setup/instance is to be used by multiple developers.
With both extension everything works well when being used directly receiving the Xdebug connection. I have a breakpoint at the last line of code and although the whole HTML content was completely sent by PHP the browser it is still waiting to do anything - although ob_end_flush() (output buffering) was already called. Stepping over the last line of code the HTML content arrives at the browser. The Xdebug log is finishing in the same way.
[Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="run" transaction_id="14" status="stopping" reason="ok"></response>
...
[Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="stop" transaction_id="22" status="stopped" reason="ok"></response>
When I now set this up using DBGp proxy the two PHP extension behave different. One is blocking the HTML output forever for all request been started and if I kill the apache processes I get a proxy log
21:01:28.652 [warn] [server] Handler response error: Error reading response: Error reading length: EOF
21:01:28.652 [info] [server] Closing server connection from 127.0.0.1:60104
21:01:28.653 [warn] [server] Handler response error: Error reading response: Error reading length: EOF
21:01:28.653 [info] [server] Closing server connection from 127.0.0.1:35422
21:01:28.653 [warn] [server] Handler response error: Error reading response: Error reading length: EOF
21:01:28.653 [info] [server] Closing server connection from 127.0.0.1:43594
21:01:28.653 [warn] [server] Handler response error: Error reading response: Error reading length: EOF
21:01:28.653 [info] [server] Closing server connection from 127.0.0.1:56398
21:01:28.659 [warn] [server] Handler response error: Error reading response: Error reading length: EOF
21:01:28.659 [info] [server] Closing server connection from 127.0.0.1:40030
while the other is delivering the HTML output and says in the proxy log the same moment
22:02:02.316 [warn] [server] Handler response error: Error reading response: Error reading length: EOF
22:02:02.317 [info] [server] Closing server connection from 127.0.0.1:33160
In both cases the Xdebug log says the same: status stopped, reason ok.
So I wonder whether the way the request seems to completely end in both cases reading an EOF and closing the server connection is really a warning because it's unexpected or whether this is the normal behaviour. And then of course it's an issue of the one PHP extension seeming not to tell the proxy and server they can end their connection (I assume this is the client's job which here is the proxy).
I checked all configuration options from Xdebug, the VSCode PHP extension and DBGp proxy to increase logging but I could not find out more than what I have described above. I tried setting the connection either via the VSCode extension or manually issuing echo -e "proxyinit -p 39001 -k jni-vscode -m 1\0" | nc 127.0.0.1 9001 with no success. The EOF warning stays and for the devsense.phptools-vscode plugin there is no php output to the browser. If anyone has a clue why I would appreciate a hint.
Thanks,
Jürgen
PS: Killing dbgpProxy makes apache deliver all the content with access_log entry showing it took 3064 seconds to fulfill the request.
1) In the first time, when I deployed the origin code to heroku server with git clone https://github.com/cleverbeagle/pup
The launching application didn't work.
I managed to correct this with to copy the content of 'settings-development.json' file and paste in Heroku => myProject => Setttings => Reveal Config Vars => Key : METEOR_SETTINGS and Value : I pasted here the content.
thanks to :
- https://github.com/cleverbeagle/pup/issues/9
- https://github.com/cleverbeagle/pup/issues/197
So, now, the app is showing on server.
2) On Chrome console, I have this error :
50d72c91808ef7fba57f920b67d152d2d57698eb.js?meteor_js_resource=true:9 WebSocket connection to 'ws://localhost:4001/graphql' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
so I changed this in METEOR_SETTINGS
"graphQL": {
"httpUri": "http://localhost:3000/graphql",
"wsUri": "ws://localhost:4001/graphql"
},
to
"graphQL": {
"httpUri": "https://myproject.herokuapp.com:3000/graphql",
"wsUri": "wss://myproject.herokuapp.com:4001/graphql"
},
Note without https and wss, the app is not showing
3) Now on Chrome Console, I have :
this warning :
50d72c91808ef7fba57f920b67d152d2d57698eb.js?meteor_js_resource=true:9 WebSocket connection to 'wss://myproject.herokuapp.com:4001/graphql' failed: WebSocket is closed before the connection is established.
and after several warning above, I have this error :
50d72c91808ef7fba57f920b67d152d2d57698eb.js?meteor_js_resource=true:9 WebSocket connection to 'wss://myproject.herokuapp.com:4001/graphql' failed: WebSocket opening handshake timed out
By using the origin source code from Pup, I can signup on server but I cannot create a new document.
Any help, please ?
Thank you
EDIT 15 JAN 2019
**4) I remove Port like this : **
"httpUri": "https://myproject.herokuapp.com/graphql",
"wsUri": "wss://myproject.herokuapp.com/graphql"
Now, I can create New document on https://myproject.herokuapp.com/documents
but I still have this warning :
fe6fa1ac83e19aa2513ac3f97293600e8dc99e8e.js?meteor_js_resource=true:9
WebSocket connection to 'wss://myproject.herokuapp.com/graphql'
failed: WebSocket is closed before the connection is established.
and this error :
WebSocket connection to 'wss://myproject.herokuapp.com/graphql'
failed: Error during WebSocket handshake: Unexpected response code:
503
any idea ?
Thanks
Have written simple server using fastcgi++ 2.1 lib and configured fastscgi in apache2 web server. When I make post request to the server with Content Type: application/json, server throws an internal server error. Have checked apache error.log file and found following log:
[Wed Jan 08 13:56:40 2014] [error] [client 127.0.0.1] FastCGI: server "/var/www/testserver" stderr: "Client sent unknown content type." from "http://abcd.com/testserver" with a POST request method.
When I set Content Type to "application/x-www-form-urlencoded" its working fine and request get served. Please help me on how to serve request with Content Type as "application/json". Is there any configuration required for this to support?
Yeah solved !
In fastcgi++ lib, Content Type "application/x-www-form-urlencoded" is hard-coded. Have changed it to "application/json" and rebuild the fastcgi++ lib. Now I'm able to serve request with Content Type "application/json".
I want to create a http2 server using node-http2 module without TLS. My code is as follows:
http2 = require('http2');
const bunyan = require('bunyan');
var log = bunyan.createLogger({name: "HTTP2 server without TLS!"});
var options = {
log: log
}
var server = http2.raw.createServer(options, function(request, response) {
console.log("Receiving HTTP2 request!");
// response.writeHead(200);
response.end('Hello world from HTTP2!');
});
server.listen(8000);
However, it does not work. When connecting to this server from chrome, it shows downloading something. When I closed the server, the downloading is finished with blank file (26 bytes).
Does anyone know what is wrong here? Do I need to configure the browser? Thanks in advance!
Chrome and all other browsers only support HTTP/2 over TLS (h2) and not plain HTTP/2 (h2c). So your browser does not understand what is returned from the server and apparently node-http2 does not send a proper error response when it receives a non-http2 request.
The problem seems not just from the browser. Using [curl] curllink that supports http2 over an http:// URL does not working either. Following is the output from the curl:
$ curl -I --http2 http://54.208.83.136:8000/ -v -k
* Trying 54.208.83.136...
* Connected to 54.208.83.136 (54.208.83.136) port 8000 (#0)
> HEAD / HTTP/1.1
> Host: 54.208.83.136:8000
> User-Agent: curl/7.47.1
> Accept: */*
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAAQAAP__
>
As we see from the curl output. It sends http/1.1 Upgrade request with proper headers set as it supposed to do according to the [http2 rfc] rfclink.
On the server side, the logs were very long, so I present here only the content of msg in the relevant three logs.
New incoming HTTP/2 connection
Client connection header prelude does not match
PROTOCOL ERROR, Fatal error, closing connection
So basically the server closed the connection because the client connection header prelude does not match. By checking the code, I figured out the error was originated from the readPrelude function of [endpoint.js] endpointlink. It is a function to read the client header, but I don't know what is wrong in the client header :(.
Thus maybe I can say the node-http2 module does not support http2 over plaintext.
Update: it turns out that I was wrong. The node-http2 module do support http2 over plaintext with direct connecting, it does not support HTTP/2 server with Upgrade from HTTP/1.1. The problem resulted from the client side using Upgrade mechanism to connect to the server not supporting Upgrade. Using nghttp client to connect sever with prior knowledge works as follows.
$ nghttp http://127.0.0.1:8000/
Hello world from HTTP2!
nghttpd server also supports HTTP2 without TLS, even though it does not support HTTP Upgrade.
$ nghttpd -d /Documents/Proxy 8080 --no-tls -v
So I highly suggest to use nghttp when you want to test HTTP2 without TLS.