kannel gateway version 1.2.1
Agilent test equipment
gateway and Apache http server running on different hosts
LAN traffic recorded on the gateway host
download to a mobile station behind the Agilent

the short version: when trying to download via WAP a (sound) file which is large, the 
gateway responds with '0x62' (bad gateway) in the status field of the Reply-PDU. 
Shouldn't it be '0x4D' (request entity too large)?

the long version: in the first Connect-PDU the mobile offers rather big client and 
server SDUs. The gateway aborts the connect, since it has SAR (segmentation and 
re-assembly) not implemented (however, the large SDUs are ACK'ed.) Now the mobile 
tries again connecting with a much, much smaller SDU, which succeeds. But trying to 
download a file larger than the currently valid (and small) SDU fails (which is 
perfectly ok.) However, the gateway sets the status of the Reply-PDU to '0x62' (bad 
gateway)!

Consulting the 'Wireless Session Protocol Specification' (5-July-2001, section 
8.2.3.3) reveals that the PDU status field should have a similar meaning than those in 
http. 

RFC 2616: the error id in question is 502. Section 10.5.3 (Bad Gateway) reads:
"The server, while acting as a gateway or proxy, received an invalid response from the 
upstream server it accessed in attempting to fulfill the request."
which is actually not the case: the very reason is that the file for download is too 
large (for whatever reason too large...) But this is handled in Section 10.4.14 
(Request Entity Too Large), error id 413:
"The server is refusing to process a request because the request entity is larger than 
the server is willing or able to process. ..." The PDU status field for this is '0x4D' 
(request entity too large)

So the question here is: is kannel right in giving back a 'bad server' status, or were 
'request entity too large' more appropriate? (Which by the way would enable the mobile 
station to bring up a more expressive error message!)

Regards
Claus






Reply via email to