Hi Jim,
> I have resources that are XML documents that I am sending using
> DomRepresentation, and I have one area where I'm looking for
> a better solution.
> I need my response to have a Content-length header.
> (Specifically, I have
> clients talking through a Windows proxy which by default uses
> HTTP 1.0. I can't
> require all my customers to change their Windows Internet
> settings to use only
> HTTP 1.1, and it appears that 1.0 waits for some sort of
> timeout if there is no
> Content-length, because it's very slow.)
That's true, HTTP 1.0 needs to know the size beforehand.
> I quickly discovered that if I call setSize on the
> Representation, my response
> will have a Content-length. However, I'm looking for a good
> way to get the
> length from the DomRepresentation. My current method is to
> write it to a
> ByteArrayOutputStream and get the resulting length from that,
> but that seems
> rather inefficient. Is there a more direct way to get it?
Not really, buffering the output is the only solution in your case. However,
you should reuse the buffer to send the response instead of serializing your
DOM twice.
> I understand that this is likely a limitation of the
> underlying DOM API, but I
> thought I'd check whether anyone here knew of something I'd
> missed in either the
> DOM API or DomRepresentation itself.
The best approach would be to write a SizeFilter that would:
- detect if the size has been provided
- if this is true, don't do anything
- if not:
- write the content to an internal buffer (ByteArray)
- replace the response entity by an InputRepresentation, passing a
ByteArrayInputStream instance wrapping the buffer
- set the size of InputRepresentation using the buffer size
I hope this helps.
Best regards,
Jerome
