Daniel Fagerstrom napisał(a):
Grzegorz Kossakowski skrev:
Daniel Fagerstrom napisał(a):
Yes, we did. Here I'm talking about fall-back mechanism so called
servlet does not have to deal with SAX. The idea was to POST
serialized SAX stream in request body. However, this solution is
problematic if we have to merge that data with the one sent by browser.
This fallback mechanism was to still stay compliant with standard HTTP
technique and adding SAX handling just for a sake of performance.
WDYT?
I agree.
Actually, I was asking about "problematic" part. ;-)
In order to avoid unnecessary serializing of SAX buffer we could implement lazy creation of request body so only if
servlet asks for it (becase it's dumb and does not handle SAX extension to the request object) the serialization occurs.
However, if original request contained parts we must forward it. If called servlet tries to parse parts (only to handle
uploads) and already got SAX buffer we have no option to serialize it because we need to return complete set of parts.
Do you have idea how to avoid this?
I'm not sure if I follow you here. Do you want to say that parts
parsing should work in lazy mode, so if caller of service does not
deal with parts double parsing is avoided, right?
That would also be a possibility. I rather meant that instead of
indiscriminately parsing all multi part mimes in a filter, the actual
parsing should be done first in the servlet service that actually is
intending to use the parts.
Right but we know if particular sitemap's servlet is going to use parts?
--
Grzegorz Kossakowski
