RE: Web Service that requires XML document in HTTP Header

[Nick Townsend <Nick.Townsend@xxxxxxxxxxxxxxx>]

Scott,

The whole XML document has to be sent in one custom field in the HTTP
request headers. I'm glad that you think this is a bad idea too! We
are considering our options, but at the moment customising the API
looks like the quickest solution. I'll keep you posted.

Nick
__________________________________
Nick Townsend
Technical Leader
Endsleigh Insurance Services Limited
Telephone: +44 (0)1242 866866 ext. 6426


-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: 12 February 2008 14:38
To: HTTPAPI and FTPAPI Projects
Subject: Re: Web Service that requires XML document in HTTP Header

Hi Nick,

What part of the HTTP header is the request sent in?   If it's sent as
part of the Request-URI, then this is a very common requirement, and is
the main reason that the peURL parameter was increased to 32k in length.

If it's stored in some sort of a custom HTTP keyword, then the
HTTP_POINT_ADDL_HEADER is your best bet.  To preserve backward
compatibility, I'd create a new xproc named HTTP_POINT_ADDL_HEADER_LONG
(or something similar) that's identical to ADDL_HEADER, except that it
uses a 32k parameter instead of the 1k one.  If you go this route,
please keep in mind that the XML document must follow the rules of an
HTTP header.  HTTP headers are limited as to which characters can be
placed inside them. Often custom keywords end up being base64 encoded to
workaround this limitation.

If it's stored in a cookie, the best solution isn't the ADDL_HEADER
stuff, but to add some sort of a 'set cookie' routine to HEADERR4 where
you can set your own custom cookie values.   Though, this would be a
strange thing to do, since cookies are supposed to only be sent back to
the entity that set them.  Consequently, setting them on the client side
doesn't make any sense.

Including an XML document in the headers is generally not a good idea
because the length of the headers is severely limited.  Different HTTP
clients and servers have different limits, and you'll almost certainly
run into compatibility issues unless your XML document is small.
Furthermore, there may be issues with transmitting these headers through
a non-tunnelling proxy.  So, generally speaking, putting XML in the
header is not a good idea.  POST data is designed to allow a large
(practically unlimited) amount of data to be uploaded without any of
these problems.  The SOAP protocol has it's own header area to allow XML
data within the header of a SOAP message (which is normally sent in a
POST document) so that both header and body can be sent together without
issues.  Using an HTTP header instead of a SOAP header is a very poor
design choice (but, I realize, you didn't design it!)

But, yes, I'd be willing to incorporate changes like this into future
releases of HTTPAPI, provided that they don't interfere with backward
compatibility, release compatibility, or the existing features of HTTPAPI.


Nick Townsend wrote:
>    Hi,
>
>
>    We have a requirement to consume a web service that is published by
>    another company.
>    This service requires that the XML payload for the request message is
>    placed in an HTTP
>    header, not in the message body.  This seems a little "eccentric" to
>    me, especially as their
>    response message seems to have the XML in the message body. However,
>    they say that
>    they have other clients using the service and nobody has had a problem
>    with it before.
>
>
>    The problem for us is that the request messages for this service are
>    too big for the 1024
>    byte parameter to the HTTP_POINT_ADDL_HEADER callback routine.   Is
>    there another
>    way to get a header that is longer than 1024 bytes onto a request
>    generated using
>    HTTPAPI?
>
>    I've looked into the HTTPAPI code and I think that it would be
>    possible to increase the
>    1024 byte limit, but I don't want to run a customised version if I can
>    help it.  If I were to
>    make the changes to the code does it sound as if this is the sort of
>    enhancement that
>    could be incorporated into a new release, or does it sound like a bad
>    idea?
>
>
>    Thanks,
>
>
>    Nick

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------



Information contained in this email is intended for the use of the addressee only, and is confidential and may be the subject of legal professional privilege.  Any dissemination, distribution, copying or use of this communication without prior permission of the addressee is strictly prohibited.   If you have received this email in error please notify the Help Desk at Endsleigh on 01242 866866. 
The contents of an attachment to this email may contain software viruses, which could damage your computer system. While Endsleigh has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage, which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment. 
www.endsleigh.co.uk
Endsleigh Insurance Services Limited is authorised and regulated by the Financial Services Authority, this can be checked on the FSA Register by visiting their web site at www.fsa.gov.uk/register
Company number: 856706 
Registered in England at Shurdington Road, Cheltenham Spa, Gloucestershire GL51 4UE


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------