Is it possible to change the path of Meteor's own websocket (DDP) requests? I need it to setup load balancers properly.
For example: changing this path "ws://localhost:3000/sockjs/839/ui4qa1rb/websocket" to “ws://localhost:3000/something/sockjs/839/ui4qa1rb/websocket"
This is done by setting ROOT_URL property.
Related
By using http.proxyHost for apache camel http component .
It need two steps below, otherwise http.proxy will not work for camel http component.
put -Dhttp.proxyHost at java command line
at camel http query paramter, setting useSystemProperties to true
but for javax.net.ssl.trustStore , step 2 is not need.
Since both of them(trustStore or httpProxy) are system properties could be used via java command line.
Why http.proxyHost need step2, but javax.net.ssl.trustStore does not ?
Could anyone have some idea?
Thanks in advancace!
Apache Camel HTTP component provide a per URI / Endpoint way of configuring an HTTP proxy:
from("direct:start")
.to("http://somehost?proxyAuthHost=www.someproxy.com&proxyAuthPort=80");
Adds to that a way to override proxy configuration using a context global options:
context.getGlobalOptions().put("http.proxyHost", "someproxy");
context.getGlobalOptions().put("http.proxyPort", "someport");
This allows the org.apache.http.client.HttpClient to be consider configuration precedence when resolving and creating the HTTP proxy:
If the system properties (for the HTTP proxy) are there those will be resolved and loaded
If the HTTP proxy global options are there, those will be resolved and used instead of system properties
If an endpoint HTTP proxy configuration has been set then this configuration will be resolved and used
All of the configuration resolution steps can be skipped altogether to fallback on using all HTTP(S) related properties (within the underlying org.apache.http.client.HttpClient) from the system properties if the user wishes so by setting the useSystemProperties component option.
As a summary, you can think of the HTTP related properties resolution process as providing a set of flexible configuration options to the user to fit in all use cases.
I am creating a REST API in Go, and I want to build URLs to other resources in my replies.
Based on the http.Response I can get the Host and URL.
However, how would I go about getting the transport scheme used by the server? http or https?
I attemped to check if server.TLSConfig is nil and then assuming it is using http since it says this in the documentation for http.Server:
TLSConfig *tls.Config // optional TLS config, used by ListenAndServeTLS
But it turns out this exists even when I do not run the server with ListenAndServeTLS.
Or is this way of building my URLs the wrong way of doing things? Is there some other normal way of doing this?
My preferred solution when running http and https is just to run a simple listener on :80 that redirects all traffic to https. Then any real traffic can be assumed to be https.
Alternately I believe you can access a request's URL at req.URL.Scheme to see the protocol.
Or do you mean for the entire application? If you accept configuration to switch between http and https, then can't you look at that and see which they chose? I guess I'm missing some context maybe.
It is also common practice for apps to take a baseURL via flag or config to generate external urls with.
Meteor.absoluteUrl has a secure option which creates a HTTPS URL, so I guess Meteor only allows either the http or https protocol. So would it be any difference to not include the protocol, and just use //example.com/ as the ROOT_URL environment variable? Or it makes a difference?
Should I include the protocol for Meteor's $ROOT_URL environment variable?
The implementation of Meteor.absoluteUrl can be found here. As you can see, it modifies ROOT_URL (options.rootUrl) with https if secure is true and ROOT_URL uses the http protocol.
If you are hosting your site using https anyway, I'd recommend including it in the ROOT_URL, e.g. https://app.example.org. That's what we do and it works fine. It certainly seems easier to change an environment variable rather than modifying your code.
Note that if you don't want to specify the protocol you should set your ROOT_URL like app.example.org and not //app.example.org - again see the implentation.
Above answer is no longer true. It seems Meteor has changed implementation and now ROOT_URL must be a valid URL with either http or https.
See https://github.com/meteor/meteor/blob/87681c8f166641c6c3e34958032a5a070aa2d11a/packages/meteor/url_server.js#L8
I have been working with Iron Router, and have been under the impression that the routes run on the server. But recently I was reading through the Accounts-Entry code and noticed that, although the routes are defined in "shared", the methods used to detect if the user is signed in only exists under "client".
This lead me to think about where routes actually run. Are they running on the client, server, both? What about "server" routes?
Have a look at the Server Side Routing section of the docs.
Defining routes and configuring the Router is almost identical on the server and the client. By default, routes are created as client routes. You can specify that a route is intended for the server by providing a where property to the route...
So by adding where: 'server' to the route, you allow it to run on the server. The advantage to defining the routes in a shared directory is that the server can then use the Router object to determine paths on the client (useful for things like generating email).
My meteor server will fetch data from another source on Internet. The request has to go via a proxy. How can I specify the proxy server for server-side HTTP.call's?
You could easily make all HTTP.* calls through a proxy if only Meteor developers accepted my pull request to pass through options like proxy to the request module, on which the HTTP package is based.
Please comment on this GitHub issue to ask for that.
UPDATE: Since the Meteor devs refused to implement that change, I published an Atmosphere package that lets you transmit to Node (i.e. to the request module) any options you want.
Check out http-more on Atmosphere.
Found a solution for my problem.
I'm using Windows and could not find a way to set a default proxy for the OS as Serkan mentioned. Setting proxy server in Internet Explorer internet options LAN settings did not work. Settings proxy in winHTTP did not work. Anyone else know how to do it?
The most reasonable would be that Node read a environment variable and used that. So, I created an environment variable "HTTP_PROXY" and to see if node would read it I tried:
D:\Appl\.meteor\tools\a5dc07c9ab\bin>node -e "console.log(process.env.http_proxy)"
and it did output my variable. But, when trying to make a http.get() request directly within Node it failed. Node is obviously not using that variable ...
The conclusion of that is that I have to explicitly set the proxy in my app, but that is not possible with Meteor HTTP. Instead I could use the request module (that Meteor HTTP is using) and set the proxy. Not the ideal solution, because my app has to know about the proxy, but ok for my purpose.
if (Meteor.isServer) {
var request = Npm.require("request");
var makeRequest = Meteor._wrapAsync(thirdLibMakeRequest);
function thirdLibMakeRequest(options, callback) {
options.proxy = "http://myProxyServer:8080";
request(options, callback);
};
var response = makeRequest({ url: "http://UrlToSomeSite" });
}
Include the request module
Wrap the 3rd-lib async method so we can use it in Meteor
set the proxy property of the request module
use makeRequest to make requests.
Since the platform your meteor app will be running on will be behind the proxy as a whole, you'll be needing proxy access generally anyway.
Therefore, you can set your platform (os) up to connect to the proxy server by default, therefore Meteor will not necessarily know/care about the presence of a proxy since it will be transparent to it.