Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at the ColdFusion Centaur And Bolt User Group Tour (Jun. 2009) with: Ye Wang and Simon Free

GetHTTPRequestData() Breaks The SOAP Request / Response Cycle In ColdFusion

By Ben Nadel on
Tags: ColdFusion

Yesterday, when I was experimenting with SOAP request error handling inside of the ColdFusion application framework, I came across what I think is a ColdFusion bug. It seems that if you call ColdFusion's GetHTTPRequestData() method during a SOAP request, the method executes properly, returning the HTTP request data, but it breaks the SOAP response, throwing the following error:

org.xml.sax.SAXParseException: Premature end of file.

To see this in action, check out this video:

 
 
 
 
 
 
 
 
 
 

In the video, I am using CFDump to output the GetHTTPRequestData() to an external file:

Application.cfc

  • <cfcomponent
  • output="false"
  • hint="I provide application settings and event handlers.">
  •  
  • <cfsetting showdebugoutput="false" />
  •  
  • <cftry>
  •  
  • <cfdump
  • var="#GetHTTPRequestData()#"
  • format="html"
  • output="#ExpandPath( './soaprequest.htm' )#"
  • />
  •  
  • <cfcatch>
  •  
  • <cfdump
  • var="#CFCATCH#"
  • format="html"
  • output="#ExpandPath( './soaprequest.htm' )#"
  • />
  •  
  • </cfcatch>
  •  
  • </cftry>
  •  
  • </cfcomponent>

... however, the same error occurs even I simply call GetHTTPRequestData() and store the result into the Application.cfc public scope:

  • <cfset this.test = GetHTTPRequestData() />

So, it's clearly not a problem with CFDump, but rather with the invocation of the GetHTTPRequestData() method itself. Unless I am missing something obvious here, this appears to be a bug in the way that GetHTTPRequestData() interacts with SOAP-based requests. Any thoughts?




Reader Comments

Ben, did you get any fix for this. i am having the same issue. i do have a soap webservice which is not serving any wsdl, i am trying to access that but i am getting the the same error you are getting. can you post the complete code including soap header etc...thanks.

Reply to this Comment

@Manju,

There is no fix for this at the moment, other than to not use GetHTTPRequestData() in conjunction with SOAP web services calls, as far as I know. Perhaps Adobe will fix this bug in later releases.

Reply to this Comment

i have couple questions.
i have a webserver i need to access invoke some soap web servies. but there is no wsdl served by the server( it is a third party server built in some C# or so). but i have a wsdl the company sent me can i save that on to my server and point that to web service hosting server and use that. is that possible....some one on the web said it is possible. i never did anything like that. untill now what ever i use had WSDL so i used direct cfinvoke...that's it. now i am trying to use soap route...

if i can not use the above method (saving wsld locally) or get HTTP then what other route i can go...let me know and post me some sample code.. thanks for your help

Reply to this Comment

I know that this is from a long time ago, but am experiencing this error with a PDF form submission script I made.

At the beginning of the CF submission script on the server, it grabs the request content using GetHTTPRequestData(), makes it into a string, and then uses ParseXml to make it into XML data. From here, it can (or at least should) be able to traverse the data as if it was an XML file.

99% of the time, everything works fine, however, I am occassionally getting this "Premature end of file error" that I believe is sprouting from the GetHTTPRequestData(). On an error, I have the script send me an email that contains the XML data that was grabbed from the GetHTTPRequestData(), and when I get this error, the email never contains any XML markup.

So, since I have not found out elsewhere what is going on with this, I thought I would try here...

Reply to this Comment

@Justin,

It sounds like you script is fine - that something is going from with the HTTP Post to your page. If no XML is showing up in the getHTTPRequestData(), then perhaps none is actually being posted. Do you have control over the environment that is posting TO your scripts?

Reply to this Comment

These posts are being made via a submit button on a PDF form. The form is set to send XML markup to a script sitting on my server. Aside from being able to touch the PDF form, I really do not have access to the other side of things. (All of the testing we did before we launched went through just fine.)

These are used to register people for a competition at a university I work for as a student worker. Basically, the form is downloaded, filled out, and submitted, which should result in the XML data being sent in a request to the script.

I have been going back and forth between thinking that it is my script, or something in the transmission. Once I read a few places that such an error was occurring with GetHTTPRequestData() and I used that function in my code, I was thinking that maybe that was causing the issue.

The really weird thing for me is the inconsistency of the error. I would think that using Adobe Reader/Acrobat to submit a registration form would allow for easy use by people on Windows or Mac, and that using Adobe software for all submissions would result in the same functionality (the people who have had this issue have been using newer versions of Reader).

But, I would think that if it is just a transmission issue with the request, that it would eventually go through. Some people have tried submitting their registrations many times, at different times of the day (or days later), and the error is still thrown.

Reply to this Comment

@Justin,

Yeah, you'd definitely think that using something like Acrobat would maintain a consistent experience. I don't have much experience with it - perhaps the application allows you turn on and off features for "security" purposes; this might be messing with posts.

One thing to try on your own is to get the PDF and submit the form with a LOT of data - like any free form textarea, just load it up with a ton of text. It's possible that the POST size gets too big and ColdFusion is trying to handle it another way. In ColdFusion 9, I think once a POST size gets to a certain point, it actually is handles through different means (for memory optimization) and is no longer available via getHttpRequestData().... of course, I could just be making that up... but it's something worth trying.

Reply to this Comment

I'll try that. Thanks for taking the time to help me out. I've been to your site quite a few times before, and it's always been helpful. Keep up the great work!

Reply to this Comment

@Justin,

Thanks my man - good luck with the intercepting SOAP stuff; it is definitely a major pain in the butt that it breaks the incoming request.

Reply to this Comment

I am about to face the same problem as I do need to capture a custom HTTP header in web service calls. I am wondering if anyone has experimented with filter chains. We have done it successfully before to address buggy soap client. I will try a similar approach by processing a request before Cold Fusion gets to do it. I just need to pick the existing header that exists in the CGI scope to overwrite it with the custom one. Any thoughts, suggestions, comments?

Reply to this Comment

The workaround I use is: getPageContext().getRequest().getHeader("name of header here") to retrieve the request header I'm looking for. This doesn't break to SOAP calls like getHttpRequestData.

Reply to this Comment

I'm investigating a report of this error for a RESTful Webservice. Our webservice uses GetHTTPRequestData().content to suck out HTTP body which is expected to only contain the XML data as a POST request. My own client that invokes this webservice operates correctly, simply posting the XML as a string with a cfhttpparam of type text/xml.

I'm wondering if anyone has encountered the Premature End of File error with RESTful web services, or more generally when using GetHTTPRequestData but not in the context of a SOAP request.

Thanks!

Reply to this Comment

I'm thinking that the real client that invoked our webservice may have tried to invoke it with SOAP instead of a RESTful POST. I've not found any useful cross references for that error and REST, except for Ben's other blog on intercepting SOAP to convert to REST.

Reply to this Comment

Ok, we resolve this problem. Our RESTful web service and the rest of the webtop is available over port 443 on HTTPS. The client was posting to the web service over HTTP instead. When IIS redirected the client POST from http to https, the XML payload was being stripped off, thus causing the XMLParse to throw then exception attempting to parse no input, which was expected to be obtained with GetHTTPRequestData().content.

Reply to this Comment

Another Google search brings me to a post of your's Ben and solves my problem. FYI, this still exists in CF9 as far as I can tell. It turned out I had a pre-process that used GetHTTPRequestData function in my OnRequestStart function for the rest of the app.

Reply to this Comment

Hi Ben have you experienced any issues capturing request data using GetHTTPRequestData over HTTPS? I've had a system whereby we capture the SOAP content from a 3rd party system over HTTP and it has worked successfully for 12 months, and recently they have started sending to us over HTTPS and the SOAP content is empty? Headers are in tact but body content is blank. Bizarre?

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.