| There is a bug in WO 5.4 with how HTTP headers are handled when deployed in a servlet container. I reported this (5711936) and it has been marked as resolved in 'the latest seed release of Xcode 3.1, Developer preview 2. So perhaps this is the bug you are running in to. Here's how it manifested itself to me:
When WebObjects applications are deployed in servlet containers, the WebObjects application does not receive requests or generate responses directly. Instead, the WOServletAdaptor sits in between the WebObjects application and the servlet container. All requests and responses are sent to the servlet container, which then dispatches them to the WOServletAdaptor, which dispatches them to the underlying WebObjects application. Responses are handled in the same way, but in the opposite direction.
A bug exists in how the WOServletAdaptor and the WOMessage and WORequest classes handle HTTP headers. It seems that WOMessage and WORequest expect all headers to be lower-case - and that the WOServletAdaptor does not make sure all headers are lower-case.
This results in posts from a form whose enctype is "multipart/form-data" failing to update any of the variables bound to form fields.
Steps to Reproduce:
1. Create a new WebObjects project
2. Modify the main component as follows:
HTML:
<wo:WOForm>
<wo:WOTextField value = "[message]"></wo:WOTextField>
<wo:WOSubmitButton action = ""></wo:WOSubmitButton>
</wo:WOForm>
<wo:WOForm enctype = "multipart/form-data">
<wo:WOTextField value = "[message]"></wo:WOTextField>
<wo:WOSubmitButton action = ""></wo:WOSubmitButton>
</wo:WOForm>
<wo:WOString value = "[message]"></wo:WOString>
Java:
public String message;
public Main(WOContext context) {
super(context);
}
public WOComponent sayHello() {
message = "hello, " + message + "!";
NSDictionary headers = this.context().request().headers();
for(int i=0;i<headers.allKeys().count();i++) {
String header = (String) headers.allKeys().objectAtIndex(i);
System.out.println(header + ": ");
System.out.println(headers.valueForKey(header));
System.out.println(this.context().request().headerForKey(header));
}
return(this);
}
3. Build the application as both a .woa and a .war
4. Deploy the applications.
Expected Results:
Type something in the forms and click on sumbit. Both forms should behave in the same way and you should see "hello, " plus whatever you typed.
The console should show all the headers with the values repeated.
Actual Results:
When a WebObjects application is deployed in a servlet container, the following rather strange situation occurs:
When this is deployed as a .woa, it produces the following correct output:
<snip>
content-type:
( multipart/form-data; boundary=----WebKitFormBoundaryZdrwLAre6TArzAid )
multipart/form-data; boundary=----WebKitFormBoundaryZdrwLAre6TArzAid
</snip>
But when it is run in a servlet container, it produces the following, obviously incorrect output:
<snip>
Content-Type:
( multipart/form-data; boundary=----WebKitFormBoundaryonU48QK5I46+pA1T )
null
</snip>
A problem exists because the valueForHeader() method in WOMessage assumes all headers are lower-case, so when WORequest attempts to determine if the request isMultipartFormData(), it does so by asking for the contentType() - which results in a call to valueForHeader(), which in turn calls the get() method of the underlying TreeMap of _httpHeaders, but mistakenly does so with a lower-case version of the key:
(List)_httpHeaders.get(aKey.toString().toLowerCase())
The result of all of this is that if you specify the "enctype" of your form as "multipart/form-data" none of the bindings for your form will get values.
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|