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

Posted June 5, 2009 at 8:38 AM by Ben Nadel

Tags: ColdFusion

Reader Comments

Yep, I ran into this issue when using CF to secure a webservice via Basic Auth: http://www.mischefamily.com/nathan/index.cfm/2008/8/13/Basic-Authentication-With-ColdFusion

I can't remember if I reported it as bug or not.

@Nathan,

No problem, I just submitted it as a bug.

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.

@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.

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

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...

@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?

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.

@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.

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!

@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.

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?

@Henry,

You might try poking around in the GetPageContext() method:

http://www.bennadel.com/blog/758-ColdFusion-GetPageContext-Massive-Exploration.htm

I believe it should allow you access to the request headers without having to go to the getHttpRequestData() function. I'll see if I can take a look at this as I think this is a problem a lot of people will run into.

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.

This bug is still alive and kicking even on ColdFusion 9.0.1. Please vote for this bug in the Adobe bug tracker. Its bug #82776 at http://cfbugs.adobe.com

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!

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.

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.

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.

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?

Post A Comment

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.

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Supported HTML tags for formatting: <strong>bold</strong>   <em>italic</em>   <code>code</code>
	Remember my information
	Subscribe to comments
	Send me a copy of this comment