Re: Web Service that requires XML document in HTTP Header

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

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