I am running an Apache Flume http source on localhost and binding it to a port, as described in the documentation:
agent.sources.httpSource.type = http
...
agent.sources.httpSource.port = 80
Now my source is listening on http://<ip>:80. How can I modify it so it could run with a path in the url? like so: http://<ip>:80/example_path?
I didn't find anything in the documentation and in the web concerning this issue.
have you tried to simply sent the data to http://<ip>:80/example_path? As far as a I know, it should work, independently of the path within the URL. A very different thing is if you want to implement a specific behaviour depending on the path. In that case, you will have to create a custom handler for the HTTPSource source by extending HTTPSourceHandler.
Related
i'm connecting to my vpn via a proxy in order to pass some custom headers.
The way i actually do it it's by putting them in my .ovpn gonfig file, something like this:
http-proxy-option CUSTOM-HEADER Host my.host
http-proxy-option CUSTOM-HEADER User-Agent My-User-Agent
But i would like to config the proxy on the server to handle those, so if i ever need to change anything i wouldn't have to modify every configuration.
My final goal is to handle the headers on the server side of the connection in order to put only the http-proxy parameter in the .ovpn config file.
I've tried to follow a Metahackers' article on how to inject http headers with squid but it didn't work for me.
Do you have any advice or do you have resources you can point me at?
Thanks.
I'm trying to setup a Shipyard server (controller) at work, but I've run into an issue. The server is up and running, which I can confirm with curl just fine. And we've configured Apache httpd to do forwarding, as we intend for the machine running Shipyard to not be directly accessible. So basically we setup a rule for Apache that incoming requests to /shipyard map to :8080/ which is where it's being served from. So the problem is that I need a way to tell Shipyard to remap "/" to "/shipyard". When I try to go to the Shipyard homepage, nothing on the page loads correctly. For example, Shipyard tried to load some js files:
/app/images/images.module.js
But to work with our forwarding, it needs to try to load:
/shipyard/app/images/images.module.js
With the kinds of servers I'm used to working with, this would normally be done by specifying a "context" or "base path" in your server config for it to serve from. I'm wondering how to do something similar for Shipyard?
It turns out there is already a github issue for this exact scenario:
https://github.com/shipyard/shipyard/issues/972
I have moqui running on system1 which is accessible using URL http://localhost:8080/Login.
Trying to access it from other system2 (in network) with URL replacing 'localhost' with the IP of first system; it shows the first (log-in) page, but afterwards, when submitting the pages from system2, the IP in URL automatically gets changed to 'localhost'. I have looked in to the book and also searched in framework code but couldn't find something related to this.
What could be the cause of this, is there any setting in app to fix this?
There are two parts to configuring hosts and ports for a webapp. One is is for the servlet container so it knows what to listen to and the other is in Moqui Framework itself so it knows what to use when generating URLs. It sounds like the issue you are having is with the second, with URL generation.
In your runtime Moqui XML Conf file there should be a webapp element somewhat like this one from the MoquiProductionConf.xml file:
<webapp name="webroot" http-port="" http-host=""
https-port="" https-host="" https-enabled="false"
content-prefix-secure="" content-prefix-standard="" cookie-domain="">
<root-screen host=".*" location="component://webroot/screen/webroot.xml"/>
</webapp>
When no #http-host/etc attribute is specified the values from the HttpServletRequest object will be used. These will vary depending on the settings of the servlet container you are using to deploy Moqui Framework.
To set it to something explicit you can use the http-host and if needed the https-host, http-port, and https-port attributes. For virtual host support the http-host and https-host attributes should be empty and the servlet container (and any proxy/etc in front of it) should be configured to pass through the hostname requested.
I'm using Composer with Toran Proxy hosted on a personal server to manage my package dependencies for Symfony2, today I encountered a problem, one of the URLs that Composer needs to download ends with dependecy-injection.json, every other URL downloads OK, but having those words it's something the proxy doesn't like, so it blocks it.
I have full access to the server, is there a way to mask o change that certain URL to make it look like another one and so "bypassing" the proxy?
This is the URL:
http://domainexample/toran/web/app.php/repo/packagist/p/symfony/dependency-injection.json
I'm using Apache2 as web server.
I need to setup intern to test ajax calls from a different server. I set everything up sort of following the official wiki in this address
https://github.com/theintern/intern/wiki/Using-Intern-to-unit-test-Ajax-calls
My config file has proxyUrl set to http://localhost:8080/sub
and http://localhost:8080/sub is setup as a reverse proxy to inter-runner in http://localhost:9000
When I run ./node_modules/.bin/intern-runner -config=tests/config from the tests root folder, the browser opens up and is able to request several files, until it tries to request the config file. That's when it receives a 404, because it requests the wrong address - http://localhost:8080/tests/config.js - without the sub folder.
I'm wondering if I'm missing something inside the config file, or if intern is not able to use proxies with subfolders. I tried to set the baseUrl parameter, but it had no effect.
Any ideas?
Update:
It seems that sometimes intern-runner uses the path provided in the config param, and sometimes it uses the one in the proxyUrl parameter inside the config file. As a workaround, what I did was to place the config file and the tests on 2 folders (actually I made a symbolic link). The first on tests/ and the second on sub/tests/ and ran it using ./node_modules/.bin/intern-runner -config=sub/tests/config.
It works, but it's kind of stupid and I really wished there was a better way to do it.
This is indeed a limitation/bug of intern. It assumes that the proxy sits at the root of the absolute domain name, i.e. that it has a pathname of /.
An issue has been created on intern's github repository here and the corresponding pull request that fixes the problem is here. Hopefully this gets merged into the upcoming 2.1 release of intern.