Scalable OGo (SOGo)

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004252SOGoBackend Generalpublic2017-08-18 10:352017-10-11 03:49
Reportermcmer 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
Platformamd64OSOpenBSDOS Version6.1
Product Version2.3.19 
Target VersionFixed in Version 
Summary0004252: http response code 204 MUST NOT carry Content-Length header
DescriptionWhen responding to a PUT of an existing calendar entry sogo responds with 204 but adds a Content-Length header.

This is in violation of RFC 7230 3.3.2, p.30.

The issue surfaced when OpenBSDs relayd(8) as reverse proxy did not accept such invalid responses and returned code 500 (Internal Server error).
Steps To ReproduceRun sogo behind relayd(8) as reverse proxy.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0012186)
mcmer (reporter)
2017-08-19 07:13

I made an attempt at a patch, which did NOT help:

--- SoObjects/SOGo/SOGoObject.m.orig Fri Aug 18 16:44:44 2017
+++ SoObjects/SOGo/SOGoObject.m Fri Aug 18 16:44:12 2017
@@ -1544,7 +1544,10 @@
          [r appendContentString: content];
        }
       else
- [r setStatus: 204];
+ {
+ [r setStatus: 204];
+ [r deleteHeaderNamed: @"Content-Length"];
+ }
     }
   else
     [r setStatus: 400];
(0012366)
mcmer (reporter)
2017-10-11 03:49

It's not just PUTs that are responded to with 204 + Content-Length.

I think every response of 204 gets that (wrong) Content-Length header.

Another example that triggers the 500 by OpenBSD's relayd(8):
GET /SOGo/so/username/Calendar/6B56-559BDB80-5-6B8B4580/canAccessContent

- Issue History
Date Modified Username Field Change
2017-08-18 10:35 mcmer New Issue
2017-08-19 07:13 mcmer Note Added: 0012186
2017-10-11 03:49 mcmer Note Added: 0012366


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker