Stefano Bagnara wrote:
> > It is a bit chaotic, and we're trying to decide how to expose
> > header parsing. ATM you can access some parsing via Fields
> > object and some other parsing via AbstractField.parse method
> > (or, as we are going to remove this, I suggest you to
> > instantiate a DefaultFieldParser class).
Thanks for those details.
I've tried to use a DefaultFieldParser (by instantiating it
using its default ctor) and its parse() method, but the resulting
field body still returns the extra space in front of the body.
If I use AbstractField.parse(), then for some headers that
works (there is no space anymore in front of the body) but for
other fields, it leads to an NPE:
Field f = ...;
LOG.warn("FIELD RAW: " + f.getRaw());
AbstractField.parse(f.getRaw()); // line 188
[WARN] MultipartResponseBody - FIELD RAW: Content-length: 206
java.lang.NullPointerException
at_org.apache.james.mime4j.field.DelegatingFieldParser.parse(DelegatingFieldParser.java:51)
at_org.apache.james.mime4j.field.AbstractField.parse(AbstractField.java:171)
at_org.apache.james.mime4j.field.AbstractField.parse(AbstractField.java:63)
at_org.expath.httpclient.impl.MultipartResponseBody.handleParserState(MultipartResponseBody.java:188)
...
I am not sure to use this API the right way though...
Regards,
--
Florent Georges
http://www.fgeorges.org/
