ampersands in caldav cause parsing error



  • I have 2 sogo accounts. One of them has an ampersand in username.
    The one with ampersand fails to sync (couldn't parse multistatus XML element)

    After reducing the case to the most minimal example, and after anonimization, here are the 2 xml files:


  • developer

    Hello,

    Thanks for the report. As far as I know, ampersands have to be encoded as entities in XML, don’t they?

    If you agree, can you please report this to SOGo and provide a link for reference here?



  • As far as I know, ampersands have to be encoded as entities in XML, don’t they?

    Yes, and they are (open the attachment in a text editor to see this, it seems the forum opens them inline, thus decoding entities)

    To avoid confusion, i include them inline:

    Working

    <?xml version="1.0" encoding="utf-8"?>
    <D:multistatus xmlns:D="DAV:" 
      xmlns:a="urn:ietf:params:xml:ns:caldav">
      <D:response>
        <D:href>/SOGo/dav/foo@example.net/Calendar/personal/</D:href>
        <D:propstat>
          <D:status>HTTP/1.1 200 OK</D:status>
          <D:prop></D:prop>
        </D:propstat>
        <D:propstat>
          <D:status>HTTP/1.1 404 Not Found</D:status>
          <D:prop>
            <a:calendar-data/>
          </D:prop>
        </D:propstat>
      </D:response>
      <D:response>
        <D:href>/SOGo/dav/foo@example.net/Calendar/personal/19A7-5CAA4180-15-5207B580.ics</D:href>
        <D:propstat>
          <D:status>HTTP/1.1 200 OK</D:status>
          <D:prop>
            <a:calendar-data>BEGIN:VCALENDAR
    PRODID:-//Inverse inc./SOGo 4.0.7//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:Europe/Paris X-LIC-LOCATION:Europe/Paris BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:19A7-5CAA4180-15-5207B580 SUMMARY:foo CLASS:PUBLIC X-SOGO-SEND-APPOINTMENT-NOTIFICATIONS:NO TRANSP:OPAQUE DTSTART;TZID=Europe/Paris:20190408T100000 DTEND;TZID=Europe/Paris:20190408T104500
    CREATED:20190407T182922Z
    DTSTAMP:20190407T182922Z
    LAST-MODIFIED:20190407T182922Z
    END:VEVENT
    END:VCALENDAR</a:calendar-data>
          </D:prop>
        </D:propstat>
      </D:response>
    </D:multistatus>
    

    Not working

    <?xml version="1.0" encoding="utf-8"?>
    <D:multistatus xmlns:D="DAV:" 
      xmlns:a="urn:ietf:params:xml:ns:caldav">
      <D:response>
        <D:href>/SOGo/dav/c&amp;m@example.net/Calendar/personal/</D:href>
        <D:propstat>
          <D:status>HTTP/1.1 200 OK</D:status>
          <D:prop></D:prop>
        </D:propstat>
        <D:propstat>
          <D:status>HTTP/1.1 404 Not Found</D:status>
          <D:prop>
            <a:calendar-data/>
          </D:prop>
        </D:propstat>
      </D:response>
      <D:response>
        <D:href>/SOGo/dav/c&amp;m@example.net/Calendar/personal/3E5C-5CAB8E00-35-469F7780.ics</D:href>
        <D:propstat>
          <D:status>HTTP/1.1 200 OK</D:status>
          <D:prop>
            <a:calendar-data>BEGIN:VCALENDAR
    PRODID:-//Inverse inc./SOGo 4.0.7//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:Europe/Paris X-LIC-LOCATION:Europe/Paris BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:3E5C-5CAB8E00-35-469F7780 SUMMARY:foo CLASS:PUBLIC X-SOGO-SEND-APPOINTMENT-NOTIFICATIONS:NO TRANSP:OPAQUE DTSTART;TZID=Europe/Paris:20190408T100000 DTEND;TZID=Europe/Paris:20190408T104500
    CREATED:20190407T182922Z
    DTSTAMP:20190407T182922Z
    LAST-MODIFIED:20190407T182922Z
    END:VEVENT
    END:VCALENDAR</a:calendar-data>
          </D:prop>
        </D:propstat>
      </D:response>
    </D:multistatus>
    
    

  • developer

    I see. Can you please provide the full DAVx⁵ exception info (which includes details about the exception, a stack trace etc)? This sounds really strange, because DAVx⁵ uses the Android XML parser and doesn’t parse by itself… Steps to reproduce would also be helpful.


Log in to reply