james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefano Bagnara (Commented) (JIRA)" <mime4j-...@james.apache.org>
Subject [jira] [Commented] (MIME4J-203) RawField parsing problem in case of '\t' delimiter
Date Fri, 30 Sep 2011 21:15:47 GMT

    [ https://issues.apache.org/jira/browse/MIME4J-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118453#comment-13118453
] 

Stefano Bagnara commented on MIME4J-203:
----------------------------------------

@Jostya: I read it twice. No way it says the tab belongs to the field name and not to the
body or that the tab is to be collapsed to the separator (the ":"). So it still belongs to
the body. Then when you evaluate the body you follow that rule (also the rule says they have
to be collapsed to a single space, not ignored, nor removed). Last thing: it is better to
check latest RFC as RFC822 is obsolete. RFC5322 says:
------
3.6.1. The Origination Date Field


   The origination date field consists of the field name "Date" followed
   by a date-time specification.

   orig-date       =   "Date:" date-time CRLF
------
You see everything after "Date:" is a date-time token for the grammar. And the date-time token
is defined as I previously quoted (may start with FWS).
The obsolete rfc822 also allows spaces between "Date" and the ":" (, but BEFORE the ":").

------
4.5.1. Obsolete Origination Date Field


   obs-orig-date   =   "Date" *WSP ":" date-time CRLF
------

Everything after the ":" belong to the body and I still can't find any sentence in the rfc
alluding to something else.


@Oleg: Yes, I agree that they should be consistent (I simply said I didn't agree with the
analysis of the rfc pointer provided). My main point is that the date header body parser should
correctly accept initial FWS as the specification says it have to. I remember the main cause
I left that space handling in RawField during last refactoring is because removing that we
produced mimemessages that was uncommon because setting most header would result in "headename:headervalue"
with no space, while the most common mime format found out there have a space and I believe
some processing tool even doesn't happily accept an header without spaces after the ":" (it
is almost a de fact standard): maybe we discussed this in the list, I don't remember right
now, sorry.
                
> RawField parsing problem in case of '\t' delimiter
> --------------------------------------------------
>
>                 Key: MIME4J-203
>                 URL: https://issues.apache.org/jira/browse/MIME4J-203
>             Project: JAMES Mime4j
>          Issue Type: Bug
>          Components: dom
>    Affects Versions: 0.7
>         Environment: linux 3.0.1, x86_64
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>            Reporter: Kostya Gribov
>             Fix For: 0.7.1
>
>         Attachments: patch
>
>
> RawField doesn't drop '\t' char between field header and body, so body starts from LWSP-char
that should be ignored by RFC822 (see 3.4.2 in spec) because date field is structured. So
date isn't extracted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message