X-Wap-Application-Id header location
while trying to send a push message from MMSC to Kannel over PAP we found that Kannel handles it in incorrect way which causes broken smpp packets. According to this http://www.openmobilealliance.org/tech/affiliates/wap/wap-250-pusharchoverview-20010703-a.pdf or that http://www.openmobilealliance.org/tech/affiliates/wap/wap-249-ppgservice-20010713-a.pdf document, X-Wap-Application-Id is described as a header of [PushMsg], which is encapsulated into HTTP transport. Despite this, Kannel supposes this X-Wap-Application-Id header inside HTTP transport and not inside Push Message.
#2 Updated by Stipe Tolj almost 8 years ago
- Status changed from New to Assigned
- Assignee set to Stipe Tolj
- Target version changed from 1.4.2 to svn
The bug has been confirmed. We need to process it within the HTTP header of the payload content part of the multi-part MIME type. NOT the meta-level HTTP headers.
#3 Updated by Stipe Tolj almost 8 years ago
- File gateway-x-wap-app-id.diff gateway-x-wap-app-id.diff added
- Status changed from Assigned to Resolved
The issue has been fixed. Please see the attached patch/diff file with the changes agains the current SVN trunk tree.
Kindly please apply, test and confirm, so we can committ the changes to the SVN repo.
#4 Updated by Stipe Tolj almost 8 years ago
patchset has been confirmed in a production environment by Rafael Aquino <rafael.lfa at gmail.com>, see reference Msg-Id:<CA+iNECYU0bGWbTYE5Ct54jH8YpxTpXaLzpxtKwYA4DMp6ssMEg@mail.gmail.com>.
#5 Updated by Stipe Tolj almost 8 years ago
- Status changed from Resolved to Closed
patchset commited to SVN trunk:
2012-10-01 Stipe Tolj <stolj at kannel.org>
* gw/wap_push_pap_[compiler|mime].c: process the 'X-Wap-Application-Id'
within the HTTP header of the payload content part of the multi-part
MIME type, and NOT inside the meta-level HTTP headers. * test/test_pgg.c: ensure we inject the 'X-Wap-Application-Id' header
to the correct section of the payload multi-part MIME type content.
This patchset fixes bug #551 and has been confirmed in production.
Thanks a lot to Nikolay Khrustalev and Rafael Aquino for reporting and
providing analysis data to resolve the bug.