Closed
Bug 905029
Opened 11 years ago
Closed 11 years ago
[Buri][Shira-51004]The request sent when downloading a MMS message doesn't contain the MMS mimetype
Categories
(Core :: DOM: Device Interfaces, defect, P1)
Core
DOM: Device Interfaces
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: sync-1, Unassigned)
References
Details
Attachments
(5 files)
AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.184 Firefox os v1.1 Mozilla build ID:20130806071254 DEFECT DESCRIPTION: The request sent when downloading a MMS message doesn't contain the MMS mimetype REPRODUCING PROCEDURES: When downloading a MMS the HTTP Get request sent shall contain the application/vnd.wap.mms-message mimetype in the Content-Type header. EXPECTED BEHAVIOUR: ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: 100% For FT PR, Please list reference mobile's behavior:
Summary: [Buri]The request sent when downloading a MMS message doesn't contain the MMS mimetype, where 51004 is DT's issue ID → [Buri]The request sent when downloading a MMS message doesn't contain the MMS mimetype
Summary: [Buri]The request sent when downloading a MMS message doesn't contain the MMS mimetype → [Buri][shira]The request sent when downloading a MMS message doesn't contain the MMS mimetype
Updated•11 years ago
|
Summary: [Buri][shira]The request sent when downloading a MMS message doesn't contain the MMS mimetype → [Buri][Shira-51004]The request sent when downloading a MMS message doesn't contain the MMS mimetype
Comment 1•11 years ago
|
||
Do you mean the "Accept" header ? Because "Content-Type" can't be in GET requests. Changing components.
Component: Gaia::SMS → DOM: Device Interfaces
Product: Boot2Gecko → Core
Comment 2•11 years ago
|
||
Dietrich was this part of the expectation for v1.1 MMS work? Can you help get an engineer on this if it's a requirement for shipping MMS?
Flags: needinfo?(dietrich)
Comment 3•11 years ago
|
||
We'd need to know the consequences of this issue too.
Comment 4•11 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #1) > Do you mean the "Accept" header ? Because "Content-Type" can't be in GET > requests. it should be "Accept" header in Get.
Comment 5•11 years ago
|
||
xiupinglong, what are the (possible and actual) consequences of this ?
Flags: needinfo?(xiupinglong)
Flags: needinfo?(longxiuping)
Comment 6•11 years ago
|
||
I think Vicamo Yang know more about this and can answer your question.
Flags: needinfo?(xiupinglong)
Flags: needinfo?(longxiuping)
Comment 7•11 years ago
|
||
Dear Vicamo, Do you know the answer about comment 5? Thanks!
Flags: needinfo?(vyang)
Flags: needinfo?(dietrich)
Flags: needinfo?
Comment 8•11 years ago
|
||
sorry, mistake operate. add needinfo back for comment 2
Flags: needinfo? → needinfo?(dietrich)
Comment 9•11 years ago
|
||
Please read RFC-2616 before asking for Content-Type of a GET method. http://www.ietf.org/rfc/rfc2616.txt
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(vyang)
Resolution: --- → INVALID
Comment 10•11 years ago
|
||
(In reply to Vicamo Yang [:vicamo][:vyang] from comment #9) > Please read RFC-2616 before asking for Content-Type of a GET method. > > http://www.ietf.org/rfc/rfc2616.txt Hello Vicamo, Can you read below text and SPEC (page 16) attached? To send an MMS message, you must first create an MMS message file. The format of an MMS message file is documented in the MMS Encapsulation Protocol specification published by the Open Mobile Alliance (http://www.openmobilealliance.org) and/or the WAP Forum (http://www.wapforum.org). The MMS message file format consists of an MMS message binary header, followed by a multipart MIME message where the multipart message is encoded in a binary multipart format as defined by the WAP Wireless Session Protocol (WSP) specification. This binary MMS message file is stored on a web server using a MIME type of application/vnd.wap.mms-message and an MMS message type of m-retrieve-conf. A subset of the binary MMS header is sent as an MMS notification message (MMS message type m-notification-ind) via SMS to the mobile device together with a URL pointer to the location of the complete message.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 11•11 years ago
|
||
Comment 12•11 years ago
|
||
(In reply to Cheng-An, XIONG from comment #10) The Content-Type must be "application/vnd.wap.mms-message" if that request has content, and a HTTP GET request has no content. As for "Accept" HTTP header, that's not even mentioned in MMS/WSP specifications. You can reopen the bug, but I can ignore it. Have fun!
Comment 13•11 years ago
|
||
an example MMS log, you can open it by wireshark (www.wireshark.org/download.html)
Comment 14•11 years ago
|
||
(In reply to Vicamo Yang [:vicamo][:vyang] from comment #12) > (In reply to Cheng-An, XIONG from comment #10) > > The Content-Type must be "application/vnd.wap.mms-message" if that request > has content, and a HTTP GET request has no content. > > As for "Accept" HTTP header, that's not even mentioned in MMS/WSP > specifications. > > You can reopen the bug, but I can ignore it. Have fun! (In reply to Cheng-An, XIONG from comment #13) > Created attachment 792147 [details] > MMS_MO_1.pcap > > an example MMS log, you can open it by wireshark > (www.wireshark.org/download.html) I attached an android phone log here, for your reference.
Comment 15•11 years ago
|
||
Comment 16•11 years ago
|
||
xiupinglong if we have no user impact of this problem, I don't think we should do anything. Also, can you please tell us what these messages actually are ? If I understand correctly, the first message is when we _send_ a MMS using a POST. Is that true? And the second message is when we _retrieve_ a MMS, but in your screenshot I think we see the server answer and we can't do anything about this. Cheng-An, could you please answer these questions ? (removing the needinfo for dietrich as we already have Vicamo and I on this bug)
Flags: needinfo?(dietrich) → needinfo?(chengan.xiong)
Comment 17•11 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #16) > xiupinglong if we have no user impact of this problem, I don't think we > should do anything. > > Also, can you please tell us what these messages actually are ? > > If I understand correctly, the first message is when we _send_ a MMS using a > POST. Is that true? > > And the second message is when we _retrieve_ a MMS, but in your screenshot I > think we see the server answer and we can't do anything about this. > > Cheng-An, could you please answer these questions ? > > (removing the needinfo for dietrich as we already have Vicamo and I on this > bug) Dear, We have to follow the SPEC, in comment #11. Just like 3 ways handshake, no user impact, but it has to be followed. It's the SPEC requirement. POST is similar as GET. Please check the 2nd log, it's GET and has application/vnd.wap.mms-message. Thanks
Flags: needinfo?(chengan.xiong)
Comment 18•11 years ago
|
||
Without a user impact I doubt we'll change anything for leo, sorry. Moreover, I think your bug is invalid. The Content-Type you're refering to in the second log is the server's response. That means we obviously can't change anything here. I'll try to do a capture of what we're doing, if you already have such a capture, please attach it. I'd want a capture of both sending a MMS and receiving a MMS.
blocking-b2g: leo? → ---
Flags: needinfo?(felash)
Comment 19•11 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #18) > Without a user impact I doubt we'll change anything for leo, sorry. > > Moreover, I think your bug is invalid. > > The Content-Type you're refering to in the second log is the server's > response. That means we obviously can't change anything here. > > I'll try to do a capture of what we're doing, if you already have such a > capture, please attach it. I'd want a capture of both sending a MMS and > receiving a MMS. The second log is this one. it has devices GET request. one more log (104.71 KB, application/octet-stream) a screenshot of the log (79.90 KB, image/png) this scrrenshot doesn't contain the 2nd log.
Comment 20•11 years ago
|
||
I opened the second log on my wireshark and it seems good to me, and very similar to the screenshot... So I'll do my own capture and I'll report.
Comment 21•11 years ago
|
||
here a pcap from a send + receive session on my unagi. The capture was started as soon as the network interface is up. All headers look good to me.
Flags: needinfo?(felash)
Comment 22•11 years ago
|
||
The capture comes from a quite current B2G18 gecko. Therefore resolving as worksforme. Please reopen with detailed informations about what is wrong in this capture, if necessary. Thanks.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•