[Resin-interest] 304 Not Modified, Content-Length, and entity headers

[Илья Казначеев]

Hello *!

For some reason, Resin 3.1, when responding with 304 due to
sendError(SC_NOT_MODIFIED), is going to reply with the header
Content-Length = zero:
0x0030:  068c 94f5 4854 5450 2f31 2e30 2033 3034  HTTP/1.0.304
0x0040:  204e 6f74 204d 6f64 6966 6965 640d 0a53  .Not.Modified..S
0x0050:  6572 7665 723a 2052 6573 696e 2f33 2e31  erver:.Resin/3.1
0x0060:  2e37 610d 0a45 7870 6972 6573 3a20 4672  .7a..Expires:.Fr
0x0070:  692c 2031 3920 4465 6320 3230 3038 2030  i,.19.Dec.2008.0
0x0080:  323a 3036 3a30 3720 474d 540d 0a45 5461  2:06:07.GMT..ETa
0x0090:  673a 2022 3669 566e 4c56 2b66 4958 4922  g:.6iVnLV+fIXI
0x00a0:  0d0a 436f 6e74 656e 742d 4c65 6e67 7468  ..Content-Length
0x00b0:  3a20 300d 0a44 6174 653a 2054 6875 2c20  :.0..Date:.Thu,.
0x00c0:  3138 2044 6563 2032 3030 3820 3232 3a30  18.Dec.2008.22:0
0x00d0:  363a 3036 2047 4d54 0d0a 0d0a6:06.GMT
In fact, this isn't compliant with HTTP 1.1 specification, which reads:
[10.3.5] If the conditional GET used a strong cache validator (see section 
13.3.3),
the response SHOULD NOT include other entity-headers. Otherwise (i.e., the
conditional GET used a weak validator), the response *MUST NOT* include other
entity-headers; this *prevents inconsistencies* between cached entity-bodies and
updated headers.

And, in fact, it broke our mod_accel, which responded to client with 200 OK,
Content-Length: 0, following with full body JFIF, and was very 
surprised when
client dropped connection.

I understand that using mod_accel == DINOSAUR! in 2008, but still, why does 
resin
do that? There's a special section in 
resin/src/com/caucho/server/http/HttpResponse.java
line 365:
else if (statusCode == SC_NOT_MODIFIED || statusCode == SC_NO_CONTENT) {
  hasContentLength = true;
  os.write(_contentLengthBytes, 0, _contentLengthBytes.length);
  os.print(0);

  if (debug)
log.fine(_request.dbgId() + Content-Length: 0);
}
After I've commented that, front-end ceased malfunction and we didn't see the 
problem.

Still, is there a reason the above code is included? Maybe there's a useful 
client which
fails to work properly when it see 304 without content-length? Or it's just a 
rudiment and
can be removed?

Thanks for suggestions!



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] 304 Not Modified, Content-Length, and entity headers

[Scott Ferguson]

On Dec 19, 2008, at 2:55 AM, Илья Казначеев wrote:

 Hello *!

 For some reason, Resin 3.1, when responding with 304 due to
 sendError(SC_NOT_MODIFIED), is going to reply with the header
 Content-Length = zero:

 And, in fact, it broke our mod_accel, which responded to client with  
 200 OK,
 Content-Length: 0, following with full body JFIF, and was  
 very surprised when
 client dropped connection.

 I understand that using mod_accel == DINOSAUR! in 2008, but still,  
 why does resin
 do that? There's a special section in resin/src/com/caucho/server/ 
 http/HttpResponse.java
 line 365:
else if (statusCode == SC_NOT_MODIFIED || statusCode ==  
 SC_NO_CONTENT) {
  hasContentLength = true;
  os.write(_contentLengthBytes, 0, _contentLengthBytes.length);
  os.print(0);

  if (debug)
log.fine(_request.dbgId() + Content-Length: 0);
}
 After I've commented that, front-end ceased malfunction and we  
 didn't see the problem.

 Still, is there a reason the above code is included? Maybe there's a  
 useful client which
 fails to work properly when it see 304 without content-length? Or  
 it's just a rudiment and
 can be removed?

I've removed that in the 4.0 tree.  It was added as part of a bug  
report for some clients that needed the content-length: 0.

-- Scott



 Thanks for suggestions!



 ___
 resin-interest mailing list
 resin-interest@caucho.com
 http://maillist.caucho.com/mailman/listinfo/resin-interest



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest