Hi James,

HTTPService has a contentType property that can be set to
HTTPService.CONTENT_TYPE_XML or HTTPService.CONTENT_TYPE_FORM. If you
specify CONTENT_TYPE_FORM (the default) the 'request' that you send
needs to be an anonymous Object. The name/value pairs in the Object will
be application/x-www-form-urlencoded into the body of a POST.

If you specify CONTENT_TYPE_XML the 'request' really should be XML. If
you use this content type but pass an anonymous Object, an attempt is
made at serializing it to XML but I'd recommend generating the XML
yourself because the automatic Object serialization isn't XML Schema
aware.

If you set 'request' to be a typed AS class instance, in the
CONTENT_TYPE_FORM scenario if your type was 'dynamic', any enumerable
key/value pairs would be encoded into the POST but that's it. If the
type isn't dynamic, it has no enumerable name/value pairs so the request
body ends up empty. If you used CONTENT_TYPE_XML your instance would be
wrapped as XML but not in the way you'd want. So the moral of the story
is to stick with anonymous Objects or XML for the 'request' based on the
'contentType' you're using.

To wrap up, here's why a request may be sent as a GET versus a POST (or
vice versa), when you've explicitly asked for the other via the 'method'
property:
1. If you set the 'method' to GET but use CONTENT_TYPE_XML, the
assumption is that you want that data sent and a POST is used because an
XML payload can't be sent on the URL.
2. If you set the 'method' to POST but pass an empty 'request' (by using
CONTENT_TYPE_FORM with a non-dynamic typed instance as your 'request')
the underlying flash.net.URLLoader switches the method to GET
automatically. This is core player behavior, and I've logged a bug
asking that the user-assigned 'method' always be respected even if it
results in a POST with an empty body.

I hope that helps explain the current behavior.
Best,
Seth   

-----Original Message-----
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of James Polanco
Sent: Wednesday, August 23, 2006 6:53 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] AS HTTPService ignoring method propety

Hey all, 
I am using the ActionScript HTTPService and I found an issue with it.
I feel its a bug, but I may have been "misusing" the functionality
and I got away with it until I pushed too far. Here is the
problem/issue:

I have a JSP app that I am calling via HTTP that returns XML data. 
One of the services requires that the data comes in via POST and not
GET. No biggie, just set the method propert... or so I thought.

When I called the app it kept coming back with "" and after looking at
the HTTP headers we realized it was always coming in as a GET even
though I explicitly set it to POST. This is where things started to
get odd... some of my service calls (all routed through the same
service code) came out as POSTs and some as GETs.

I was able to track down the cause and it was all based around the
format of the object that I was passing to the request property. For
example, if I did it this way my call became a POST (as desired)

myService.request = {zip: "94103};

If I created a custom VO class that had public properties that matched
the required parameters it converts to GET on the call(protocode):

class MyZipVO
{
public var zip:String = "94103";
}

----

var temp:MyZipVO = new MyZipVO();
myService.request = temp;

I didn't catch this at first because my previous services worked as
either GET or POST but once I tried to access the one that required
POST it all blew up. Anyway, I figured it out and I can work around
it, but any idea on why this fails or if this should work in the first
place?

James



 


--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/flexcoders/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply via email to