This is just a quick post for future reference. Hopefully, it can help others in figuring out why a service behind Tivoli Access Manager’s WebSEAL is returning a 501 error from POST requests.
Recently, I wrote a client using Apache’s HttpClient for accessing a REST API protected by IBM’s WebSEAL 6. While uploading data via POST, I started receiving a mysterious 501 Not Implemented error.
The data in question was being uploaded with chunked encoding, as in the following snippet .
InputStreamEntity reqEntity = new InputStreamEntity( new ByteArrayInputStream(aString.getBytes("UTF-8")), -1, // This is the size. Not specifying it sets the encoding to chunked ContentType.APPLICATION_JSON );
HttpClient’s original example goes on and calls reqEntity.setChunked(true), but that is not strictly necessary, as when a InputStreamEntity is constructed with its size argument set to -1, chunked encoding will be used by default. Anyway, according to IBM Tivoli Access Manager’s documentation, at least for version 6.1.1, you have two options when using TAM/WebSEAL as a reverse proxy:
- Don’t use chunked encoding at all;
- Use it and accept your data will be corrupted.
Quoting reject-request-transfer-encodings‘s documentation: “WebSEAL may reject the request, or may forward it on the junctioned server in a corrupted state. This setting is available for compatibility with versions of WebSEAL older than version 6.0.” This behavior seems to appear every time the “Transfer-Encoding” header is present. Version 7.0 onwards seem to support chunked encoding just fine.
If you can know in advance what the size of the entity being sent is going to be, your best shot is to explicitly set it when sending your request.
|||Which was based on the one from HttpClient’s sample gallery.|