I thought it was a nice thing, the result ...
Such a way is very insecure, especially if exposed to public address, very easy to be attacked, and Gearman HTTP service is far from professional webserver robust.
attack mode is very easy:telnet host 8080, after the successful connection, random input point content, such as: AAA, Gearman logs are constantly appearing, such as the following error message:
Bad Request LINE:AAA
It's a dead loop. Gearmand on the top, the system memory will be exhausted, indicating that the HTTP implementation of the bug.
This bug can only be fixed by altering the source code:
You can open file libgearman-server/plugins/protocol/http/protocol.cc, find ' Bad Request line: ' and ' bad method: ', then C Hang ' gearmand_success ' to ' gearmand_invalid_packet ' after them. This is a quick for this bug.
You can also download the following patches to the source patch:
Https://bugs.launchpad.net/gearmand/+bug/1348865/+attachment/4182968/+files/gearmand-1.1.12.patch
Gearmand-1.1.12 Source Code installation folder run: Patch-p0 <. /gearmand-1.1.12.patch
The patch overcomes the above error and adds support for the Get method at the same time
bug information see:https://bugs.launchpad.net/gearmand/+bug/1348865
Original:
This protocol plugin allows-to-map HTTP requests to Gearman jobs. It is only provides client job submission currently, but it could be extended to support other request types in the future. The plugin can handle both GET and POST data, the latter being used to send a workload to the job server. The URL being requested is translated into the function being called.
For example, the request:
Post/reverse Http/1.1content-length:12hello world!
is translated to a job submission request for the function "reverse" and workload "Hello world!". This would respond with:
http/1.0 Okx-gearman-job-handle:h:lap:4content-length:12server:gearman/0.8!dlrow OlleH
The following headers can be passed to change the behavior of the job:
* X-gearman-unique: <unique key>* x-gearman-background:true* x-gearman-priority:
For example, to-run a low-priority background job, the following request can be sent:
Post/reverse Http/1.1content-length:12x-gearman-background:truex-gearman-priority:lowhello world!
The response for this request is not having any data associated with it since it is a background job:
http/1.0 okx-gearman-job-handle:h:lap:6content-length:0server:gearman/0.8
The HTTP protocol should be considered experimental.
Application Scenarios:
Turn on Gearman http snooping to let the front end invoke the Gearman job in Web API mode
How to:
In the Gearmand's starting parameters, add:
/usr/local/gearman/sbin/gearmand \
-l/usr/local/gearman/log/trace.log \
--verbose info-p 4730-u root-d-T 4 \
--http-port 8080 \
-R http
--http-port=8080 specifying the Listening port number
-R HTTP HTTP protocol module
Call Mode:
Now the HTTP protocol only supports the task submission class interface, other types of temporary not supported.
According to the official documentation, HTTP supports get and POS two way calls, but get mode I haven't figured out how to carry the data, the Post method was able to experiment
Http://172.16.18.116:8080/reverse
reverse is the function name, if the data content of the post is: "Hello world!", return Result: "!dlrow Olleh"
Some task parameters can be set in the header of http:
* X-gearman-unique: <unique key>
* X-gearman-background:true
* X-gearman-priority:
This way of use, in fact, Gearmand Monitor the two end, the original 4730-terminal is able to receive the normal Gearman protocol client request, the other 8080port is listening to the HTTP protocol request, two ways to work together, HTTP service front end such as mobile call , Gearman calls from other modules inside the service.
Invoke Gearman task processing in HTTP mode