ant-dev mailing list archives

(sending this again zipped to get under the 96Kb limit)
This little submission constitutes an extension and refactoring of
Get.java, with most of the extensions from Matt Humphrey, the
refactoring from me. Matt submitted his post code in February, I have
just made the whole design cleaner rather than made Get as
multifunctional as some of the other feature-creep tasks.
The code now adds much more functionality
+basic authorisation
+parameter list for URL or form generation
+parameter list for extra headers.
+null file output
+POST with form data
+POST with bulk data upload
+HEAD; Get without the destination and sometimes different responses from
the server
+a success property set to "true" if the request worked (completed and,
for http response code between 200 and 299)
+ability to store the results of the download into a property
+proxy server support (a task to define the server and port)
+failonerror (replacing and inverting ignoreerrors)
+better error reporting (better for unit testing anyway)
And, equally importantly, a big rework of the actual structure:-
+abstract HttpTask base class which does almost everything and provides
structured points for overrriding
+HttpGet : implements get
+HttpPost: post
+HttpHead : head protocol;
+various helper classes -
HttpAuthStrategy and subclasses: authentication
NullOutputStream (discards all input. should have been part of java.io a
long time ago)
ContentGuesser (to make UrlConnection.guessContentTypeFromFilename
public)
HttpRequestParameter (internal parameters)
I've placed all of this into a new package ant.taskdefs.http , because,
well, it keeps things less messy.
You can have some fun with these extensions, both the post stuff (what
forms do you want your build to fill in?), and the ability to store
success and contents properties. I can now test for remote boxes being
reachable, and grab information from servers to include in the process.
Some examples are (from the unit test)
<httppost url="http://www.iseran.com/cgi-bin/posttest.pl"
destinationproperty="test9"
>
<param name="p1" value="hello"/>
<param name="p2" value="world"/>
</httpget>
this sends a form to a test script and stores the result in a variable for
testing.
Another handy example is
<httphead url="http://www.apache.org/"
failonerror="false"
successproperty="reachable.apache"/>
which shows how to test for a server being available before continuing.
The tests for non-http protocols just assume any content is success; for
HTTP a response between 200 and 299 is required. So no authentication
(401), missing (404) are all failures and break the build or dont set
the succeeded property. This is the change most likely to break legacy
get tasks, where the response code was only looked at for timestamping
The post file upload lets you send preprepared files to a destination:-
<httppost url="https://www.pizzaservices.com"
uploadFile="pizza-order.xml"
contentType="text/xml">
I'm sure people will be able to think of better uses.
Also added: the documentation file and a unit test class which extends
Nico's original one. Now that the task saves the contents of downloads
to properties, it is possible to include the contents in the test -so I
am even verifying that the encoded parameters can be extracted from both
URLs and forms. There are also various tests of the success property
against real and imaginary urls. I've had to add some .pl code to my
tier 3 external web server, and a basic protection realm for the
authentication tests -these should be moved to an apache server.
Incidentally, whoever does host the server side code gets to log
whenever the test suite runs...
Things I havent tested yet, because I need a proxy server and some more
server side code are
-proxy settings
-bulk file upload
-digest auth (not written either; Matt has promised that)
I havent done the 'legacy' GET wrapper, which will just be a matter of
adding the old attribute names -unless people have subclass
dependencies or the redefinition of failure on HTTP is fatal to some
tasks. For now the new code can live side-by-side with the
old stuff.
Nor have I addressed any of the issues I listed earlier in the 'on the
operating table' message. Have a play with this stuff and then state your
opinions.
I don't think it is going to be ready to replace Get till the issues are
finalised and the wrapper in place, but the new tasks (httppost,
httpheader) can go live with less compatiblity issues, and new tasks (put,
xmlrpc) built from this foundation.
-Steve