Vue recommends that using Axios for HTTP requests. As I know, Axios use http1.1 protocol, but I want to use http2.0, how should I do? h2 has been a build-in module in nodejs at server-side, so I need h2 in vue as a client.
The HTTP/2 connection should be transparent for your browser application. You just need to make sure your server and browser support HTTP/2
When both of your server and browser support HTTP/2 your browser's XHR will use HTTP/2. You don't need to do any special setup in Vue.js
For Axios, HTTP/2 support problem only happens in the server-side. Because it is using the following adapter which calls Node.js' HTTP and HTTPS module.
https://github.com/axios/axios/blob/master/lib/adapters/http.js
There is already a pull-request for HTTP/2 support. You can try it if you want Axios HTTP/2 support in server-side
But in client-side it will use browser API - XMLHttpRequest which will follow the browser behaviour
https://github.com/axios/axios/blob/master/lib/adapters/xhr.js
Related
I am using Wiremock API with selenium as a proxy server to alter certain browser ajax calls. I started the Wiremock with certain mappings and put the proxy in the browser through selenium. Now I can access the only mapped URLs for the rest of the request getting 404. It seems wire mock is not forwarding the unmapped calls to the internet.
Is there any way to do this? or wire mock can't be used with selenium to mock only a few ajax calls.
I have a vue.js frontend and I need to make api calls to an external api which doesn't allow cross-origin.
Is there a way to proxy this in the vue frontend, in development I used a devServer proxy and this worked. I could always forward it through my own spring backend but this seems like a worse solution then just proxy in the fontend.
You can't do it in production, proxy through bachend server seems right solution for you.
Also you can do a lot of stuff, like caching answers from external api, working with data immediately, without additional frontend work. Just try to do it.
If i were you, i'd just create/add separate service on backend that should work with that api.
I have just began using socket.io and I have some experience with express. I know socket.io has bidirectional communication while express is only client to server.
This made me think, why don't we just use socket.io with different namespaces and not use express at all?
In which cases should I use socket vs express?
In the case I need bidirectional communication, is it advisable to make the client -> server with express and then use socket for server -> client?
First off express and socket.io are pretty different things. Express is a full-blown web server framework. You use it for setting up a web-site, fielding http requests from a browser, fielding http requests for an API, etc...
socket.io is a communication layer that sits on top of the webSocket protocol and the webSocket protocol uses an http server to establish its initial connection. While there is a little bit of overlap between what you can do with socket.io and Express, they are more different than they overlap.
For example, if you're setting up a web-site, you couldn't do that with socket.io, one would use something like Express.
Now, if you have a specific programmatic need to communicate between an arbitrary client and a server, you have a zillion choices. If the client is in a browser and the programmatic interface is from Javascript in the browser, then you have fewer choices.
From the browser, using http ajax requests via Express is one choice. Setting up a socket.io connection and defining you own messages is another choice.
Reasons to pick socket.io over Ajax calls to Express from browser Javascript:
You need/want two-way communication over the same channel.
The client is sending a lot of requests to the server (the overhead for sending a socket.io message is lower than an ajax call, once the socket is already set up, so if you're sending a lot of messages, then socket.io messages are more efficient than http requests)
Reasons to pick Ajax calls to Express:
HTTP connections are stateless and short-lived which can make implementing high scale, multi-server implementations with failover and redundancy easier.
There are a wealth of tools to use for http connections from authentication libraries to data formats (MIME) to audio to video, etc...
You want your client to run in places where a long-connected socket.io during inactive periods of time may not be practical (perhaps mobile or battery operated devices).
You want to run in situations where there are proxies, firewalls or other network infrastructure that may not support long running webSocket connections or specifically disallow them.
You want a request/response model. HTTP is request/response where you get a specific response for each request and you know exactly which response goes with which request.
So, as you can see, there is no generic answer to this question. It really depends upon the specific of your communication, the interoperability you desire and the exact needs of your code.
Here are some other references on this topic:
Ajax vs Socket.io
Websocket vs REST when sending data to server
Using AJAX vs. socket.io socket messages
websocket vs rest API for real time data?
I'm using the Lagom microservices framework and the Streaming requests and responses use websockets as the transport. However, the built in websocket client (netty) doesn't handle SSL connections. I understand there are various architectures where SSL termination isn't handled by Lagom itself that avoid this, but for our application we need TLS all the way to the endpoint.
The post (https://groups.google.com/forum/#!topic/lagom-framework/QcOvK8H3R94) suggests that akka-http websockets support TLS, but that isn't currently an option as a Lagom client.
This gist (https://gist.github.com/DaveDeCaprio/4db9d36a5e907fb5810c00e919347aa3) provides an example of an Akka HTTP websockets client for Lagom.
I don't include this as a full pull request in Lagom because it is still pretty hacky. The biggest issue is that the RequestHeader that is returned from a streamed call is a fake, generic Ok header. The actual HTTP call isn't made until the stream is materialized and run. This is due to a different in the way akka http and netty handle the websockets. This wasn't trivial to fix.
I'm using an application that sends SOAP requests (HTTP POST) to my application running in CloudBees PaaS (run#cloud). The SOAP sender application gets the following error from the server: Transport error: 411 Error: Length Required. This means that it should not use chunked transfer encoding, because chunked doesn't send Content-length header which the server seems to want.
Is there some reason why chunked cannot be used? I'm aware that some web servers, like Apache, might have DOS vulnerabilities related to chunked transfer encoding. Is this the reason? Or is it because run#cloud uses Nginx as a proxy?
You can now set the httpVersion end to end for your app:
To enable: httpVersion=1.1
for example, this is how WebSocket works:
https://developer.cloudbees.com/bin/view/RUN/WebSockets
You can and should also set proxyBuffering=false - (this is default for new apps).
Cloudbees Nginx router indeed uses http 1.0 so don't have chunked transfert support. As we are working on websocket support, with a new version of NGinx, this may be available soon