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)

defect

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
blocking-b2g: --- → leo?
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
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
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
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)
We'd need to know the consequences of this issue too.
(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.
xiupinglong, what are the (possible and actual) consequences of this ?
Flags: needinfo?(xiupinglong)
Flags: needinfo?(longxiuping)
I think Vicamo Yang know more about this and can answer your question.
Flags: needinfo?(xiupinglong)
Flags: needinfo?(longxiuping)
Dear Vicamo,

Do you know the answer about comment 5?
Thanks!
Flags: needinfo?(vyang)
Flags: needinfo?(dietrich)
Flags: needinfo?
sorry, mistake operate. add needinfo back for comment 2
Flags: needinfo? → needinfo?(dietrich)
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
(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 → ---
(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!
Attached file MMS_MO_1.pcap
an example MMS log, you can open it by wireshark (www.wireshark.org/download.html)
Attached image a screenshot of the log
(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.
Attached file one more log
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)
(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)
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)
(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.
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.
Attached file unagi pcap log
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)
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 ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: