OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: XML over HTTP

[ Lists Home | Date Index | Thread Index ]
  • From: David Brownell <db@Eng.Sun.COM>
  • To: "xml-dev@ic.ac.uk" <xml-dev@ic.ac.uk>
  • Date: Wed, 18 Nov 1998 18:35:59 -0800

james anderson wrote:
> 
> Greetings;
> 
> I have a simple question.
> 
> What are people doing when they read xml 'over the wire'?. It would appear
> that the logical structure of an xml document (to wit
>   [1] document ::= prolog element Misc*
> ) is at odds with the protocol specified for things like a http put operation.

No it isn't; HTTP handles NNNN bytes of data, the XML document is MMMM 
characters long, one only needs to know the number of bytes to exchange
the stuff over HTTP.  It's encoded in HTTP message header fields, or else
implicitly by the end (EOF) of the particular message.


> For which a response from the recipient cannot come until after the operation
> is performed. As a consequence of which, the input socket remain open (being a
> two-way stream in order to write the response) after the object has been read.
> In which case EOF is not a useful hint that the document is complete.

This is the same problem anyone writing POST/PUT code deals with.  The
client must use one of several techniques to terminate the request entity;
the server uses one of them to terminate the response entity.  (This is
"entity" in the MIME sense, not the XML sense.)

	- Do a half-close after sending ... use shutdown() to tweak the
	  TCP code to report EOF on that side of the connection.

	- Content-Length: NNNN ... that is, recipient reads NNNN octets
	  and that signifies end of entity.  Both close() afterwards.

	- Content-Length: NNNN ... like above, but using one of the
	  various keepalive HTTP flavors (preferably HTTP/1.1 not
	  the earlier version).  So, no close() afterwards, normally.

	- HTTP/1.1 supports chunked data, delivered in counted chunks.
	  This is like setting Content-Length, except that you can
	  avoid buffering the whole entity (e.g. a 4 Mbyte file) by
	  sending it chunk-at-a-time.

HTTP is like _any_ normal RPC protocol in that it doesn't permit response
data to be sent before the request has been read in.  There are atomicity
issues. 

- Dave



> The same problem will appliy to connections which are kept alive for
> extended communications.
> 
> We could well assert a specific document structure, - for example prescribing
> miscellaneous content after the document element, but i'm wondering what the
> general W3 intent was.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


  • References:
    • XML over HTTP
      • From: james anderson <James.Anderson@mecomnet.de>



 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS