Please file a bug. Thank you Pierre -- Pierre Frisch [EMAIL PROTECTED]
On Jan 28, 2008, at 20:26, Jake MacMullin wrote:
Yes, it does have to do with the headers. I accidentally replied to Chuck off-list, but the only difference in the headers between an app built as a .woa and one built as a .war is in the case of the header keys. It turns out that this makes a difference...There is a bug in the way WebObjects 5.4 handles HTTP headers when applications are deployed in servlet containers.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 means that when a WebObjects application is deployed in a servlet container, the following rather strange situation occurs:A HTTP request is sent to the application (via the servlet container and WOServletAdaptor) containing a Content-Type header:eg. Content-Type = ( multipart/form-data; boundary=---- WebKitFormBoundarytAEgAmILbXskfM9V);The WOServletAdaptor passes this header on to the WebObjects application, so if we were to enumerate the headers with the following code, we'd see something like: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)); } <snip> Content-Type:( multipart/form-data; boundary=---- WebKitFormBoundarytAEgAmILbXskfM9V )</snip>However, 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());This problem can be confirmed by adding the following to the earlier enumeration of headers: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)); }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>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.As for a work-around, it is pretty hacky but you can write your own WOSerlvetAdaptor sub-class and override the default implementation of doPost to change the case of any HTTP headers before handling the request.Regards, Jake MacMullin On 29/01/2008, at 11:18 AM, Chuck Hill wrote:What are the difference in headers in the two requests? Chuck On Jan 28, 2008, at 4:00 PM, Jake MacMullin wrote:Hi All,I think I've found a bug - and before I submit a bug report I thought I'd check to see if anyone else has encountered it and if there are any work-arounds.It seems that WOForms with an enctype of "multipart/form-data" are broken in WebObjects 5.4 when you're deploying an application as a WAR.I've got the following simple component: HTML: <wo:WOForm> <wo:WOTextField value = "[message]"></wo:WOTextField> <wo:WOSubmitButton action = "[sayHello]"></wo:WOSubmitButton> </wo:WOForm> <wo:WOForm enctype = "multipart/form-data"> <wo:WOTextField value = "[message]"></wo:WOTextField> <wo:WOSubmitButton action = "[sayHello]"></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 + "!"; return(this); }If I build my application as a .woa everything works as I'd expect it to, however, if I build my application as a WAR then the form with the enctype of "multipart/form-data" fails. My instance variable does not get assigned a value - but remains null.This is obviously a problem as it means that WOFileUpload doesn't work with WO 5.4 applications built as a WAR. Anyone else encountered this? Any idea of a work-around?Regards, Jake _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net This email sent to [EMAIL PROTECTED]--Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.http://www.global-village.net/products/practical_webobjects_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/pierre%40apple.com This email sent to [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
