asked on

POST via XMLHttpServer fails - maybe wrong Content-Type?

I have a VB6 application that uses HTTPs to send files over the internet. The files contain simple ASCII text - not to any XML or HTML format standard.

Everything normally works well until I POST a file that contains the '&' (ampersand) character; these files get truncated at the receiving end - only the data before the '&' is apparently received. I am pretty sure that this can be rectified by using a particular 'Content-Type'. Currently the code does not specify a content-type and I am not sure what the default is.

Any clues gratefully received.

jmelika

Have you considered doing a replace(content,"&","XX1XX"), or whatever else that would be unique, then at the server you could read it and do another replace(content,"XX1XX","&")?

JM

Andy_Needham

ASKER

Thanks - but no can do! The server is not mine - it belongs to a service provider. At the moment I am replacing '&' with 'and', but there are some circumstances where this is not acceptable.

jmelika

I see. Well thats certainly a tricky one. If your saved file will be displayed as HTML, you might get away with converting your & sign into HEX. 7 in HEX is %26

Good luck!
JM

jmelika

Sorry. I meant to say "& in HEX is %26" instead of saying "7 in HEX is %26" I guess it's time to clean my keyboard :-D

JM

Andy_Needham

ASKER

Thanks - the trouble is that the file is a fixed format text file that is to be parsed by an automated service; it doesn't do any interpretting :-(

I still reckon that the answer might lie in the CONTENT-TYPE, but I am not sure where to get a definitive list of the available options and their effect.

ASKER CERTIFIED SOLUTION

jmelika

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

rdcpro

You need to escape the ampersand into the entity for Ampersand, which is & The remote server should be able to expand the entity into the character. What you're describing sounds like a parser error.

To verify, try putting a left pointy bracket in the text: <

This should break the POST as well. If so, you need to escape &, < and >.

Regards,
Mike Sharp

rdcpro

Oh, to set the content type you use setRequestHeader.

oXMLServerHTTPRequest.setRequestHeader("Content-type", "text/plain")

Or more likely, you want to set it to:

oXMLServerHTTPRequest.setRequestHeader "Content-type", "application/x-www-form-urlencoded"

But then you probably need to URL encode the ampersand, plus any other special character.

Regards,
Mike Sharp

SOLUTION

rdcpro

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

jmelika

rdcpro,

I don't believe your suggestion in your first post will make a difference. He cannot post & since it DOES contain the & sign which we're trying to posting.

I do like your last point about
oXMLServerHTTPRequest.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"

JM

rdcpro

But a single ampersand in the body of a POST will still cause the problem unless it is urlencoded...

Whether or not the & works depends on what's parsing the request. I generally construct XML documents rather than a form body, and post that, because it's easier to validate and read on the remote end. Obviously here the poster does not have control over the remote server...

In any case, I can repro the issue on one of my local dev machines. A post containing a form field with an ampersand gets truncated at the ampersand. Any following fields are undefined. If I escape the & to %26 (or urlencode the field), no problem -- as long as the content type is set to application/x-www-form-urlencoded.

Regards,
Mike Sharp

Andy_Needham

ASKER

Thanks for all the input. I have been conducting some tests with the service provider and I am awaiting results. It seems that the problem might be with the service provider, in which case I will need advice regarding allocation of points!

Andy

Andy_Needham

ASKER

The service provider has agree to modify his system, so the problem has disappeared.

Thanks to JM and Mike for your helpful input though!

Andy