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