Oleg Kalnichevski wrote:
MIME is a transfer encoding not a content encoding (at least imo). So,
we would still be allowed to develop multipart components. This said, I
would rather prefer to migrate multipart related code to Commons Codec.
There's already multipart-codec project in the Commons Sandbox
I'd like to see Multipart-MIME outside HttpClient project as well. As an
optional dependency.
+ * {{{ Jakarta Http Components }}} develops an HTTP connector or a
lightweight server component as a reference material to demonstrate
the capabilities of the toolset. The said artifacts '''ARE NOT'''
meant for production use and are not released as official Apache
Jakarta products.
I would rephrase this so it is logically "not client" instead of
"server" component. This would allow us also to create a proxy
implementation (which we will need for testing purposes anyway).
A full-fledged HTTP/1.1 compliant caching proxy or reverse proxy would
be a major undertaking and should be developed as a separate project.
Let us keep it out of scope for the time being. We simply have no
resources for such a massive effort.
Oleg
I know that this is complex, Oleg. And I know that there are projects
(Built-in cache in Magnolia for instance) that were trying to do it and
have failed miserably. And I would never go down the road to build a
fully fledged proxy. But we actually have a simple (i.e. not fully
compliant) implementation already. This has two benefits:
* we can use it for our test suite and simulate any (odd) proxy behaviour
* we ensure that the components we build are useful for building a
proxy (same argument as for server code)
The problem with our current proxy code is that it needs to buffer the
content completely. It is currently impossible to write a non-buffering
proxy.
Odi
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
