[Buri][Shira-51004]The request sent when downloading a MMS message doesn't contain the MMS mimetype

RESOLVED WORKSFORME

Status

()

P1
normal
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: sync-1, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

5 years ago
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:
(Reporter)

Updated

5 years ago
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

Updated

5 years ago
blocking-b2g: --- → leo?
(Reporter)

Updated

5 years ago
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

5 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
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.

Comment 4

5 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.
xiupinglong, what are the (possible and actual) consequences of this ?
Flags: needinfo?(xiupinglong)
Flags: needinfo?(longxiuping)

Comment 6

5 years ago
I think Vicamo Yang know more about this and can answer your question.
Flags: needinfo?(xiupinglong)
Flags: needinfo?(longxiuping)

Comment 7

5 years ago
Dear Vicamo,

Do you know the answer about comment 5?
Thanks!
Flags: needinfo?(vyang)
Flags: needinfo?(dietrich)
Flags: needinfo?

Comment 8

5 years ago
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
Last Resolved: 5 years ago
Flags: needinfo?(vyang)
Resolution: --- → INVALID

Comment 10

5 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

5 years ago
Created attachment 792055 [details]
OMA-TS-MMS_ENC-V1_3-20110913-A.pdf
(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

5 years ago
Created attachment 792147 [details]
MMS_MO_1.pcap

an example MMS log, you can open it by wireshark (www.wireshark.org/download.html)

Comment 14

5 years ago
Created attachment 792149 [details]
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.

Comment 15

5 years ago
Created attachment 792154 [details]
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)

Comment 17

5 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)
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

5 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.
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.
Created attachment 792778 [details]
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
Last Resolved: 5 years ago5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.