Closed
Bug 804754
Opened 12 years ago
Closed 12 years ago
B2G MMS: support UAProfile in HTTP header
Categories
(Core :: DOM: Device Interfaces, defect)
Tracking
()
People
(Reporter: philikon, Assigned: ctai)
References
Details
(Keywords: dev-doc-needed)
Attachments
(2 files, 4 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
When fetching resources for MMS via HTTP, the device's UAProfile (URL) should be sent along in an HTTP header (usually X-WAP-Profile).
Comment 1•12 years ago
|
||
OMA User Agent Profile V2.0:
http://www.openmobilealliance.org/Technical/release_program/uap_v2_0.aspx
OMA User Agent Profile V1.1:
http://www.openmobilealliance.org/Technical/release_program/uap_v11.aspx
Updated•12 years ago
|
Blocks: b2g-mms-conformance
Assignee | ||
Comment 2•12 years ago
|
||
1. Due to the specification different, we need a place to put the configuration for device specified settings for MMS. Different devices should have different UAProf url to point out the device ability.
2. We might need a mechanism to set and maintenance framework wide MMS configuration, like UAProd url, max message size, max image height/width for an attachmented image and so on.
3. We might need a website to put xml file for UAProf for default FFOS settings.
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → ctai
Assignee | ||
Updated•12 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 3•12 years ago
|
||
This a WIP patch with debug parts for getting some feedbacks.
I will remove debug related codes in fix patch.
Assignee | ||
Comment 4•12 years ago
|
||
Attachment #685935 -
Attachment is obsolete: true
Assignee | ||
Updated•12 years ago
|
Attachment #685936 -
Flags: feedback?(vyang)
Comment 5•12 years ago
|
||
Comment on attachment 685936 [details] [diff] [review]
WIP-Add UAProfile url into HttpRequest hader
Review of attachment 685936 [details] [diff] [review]:
-----------------------------------------------------------------
Nice! But next time you request for review/feedback, please remove all the local debug code, so the review won't ask a lot unnecessary question and waste time on dead code.
Attachment #685936 -
Flags: feedback?(vyang) → feedback+
Assignee | ||
Comment 6•12 years ago
|
||
Attachment #685936 -
Attachment is obsolete: true
Assignee | ||
Comment 7•12 years ago
|
||
Comment on attachment 685949 [details] [diff] [review]
Add UAProfile url into HttpRequest hader
Excerpt descriptions from OMA-TS-UAProf-V2_0-20060206-A.pdf, the User Agent Profile specification is concerned with capturing classes of device capabilities and preference information. And the User Agent Profile (UAProf) specification extends WAP 2.0 to enable the end-to-end flow of a User Agent Profile
(UAProf), also referred to as Capability and Preference Information (CPI), between the WAP client, the intermediate network points (proxies and gateways), and the origin server.
So I use the preference name "wap.UAProfile.url" and "wap.UAProfile.tagname".
Attachment #685949 -
Flags: review?(vyang)
Assignee | ||
Comment 8•12 years ago
|
||
Try server result:
https://tbpl.mozilla.org/?tree=Try&rev=8651d93eb072
Assignee | ||
Comment 9•12 years ago
|
||
Try server result:
https://tbpl.mozilla.org/?tree=Try&rev=8651d93eb072
Comment 10•12 years ago
|
||
Comment on attachment 685949 [details] [diff] [review]
Add UAProfile url into HttpRequest hader
Review of attachment 685949 [details] [diff] [review]:
-----------------------------------------------------------------
Nice!
::: dom/mms/src/ril/MmsService.js
@@ +59,5 @@
> Services.obs.addObserver(this, kNetworkInterfaceStateChangedTopic, false);
> + try {
> + this.urlUAProf = Services.prefs.getCharPref('wap.UAProf.url');
> + } catch (e) {
> + this.urlUAProf = "";
Indentation here
@@ +64,5 @@
> + }
> + try {
> + this.tagnameUAProf = Services.prefs.getCharPref('wap.UAProf.tagname');
> + } catch (e) {
> + this.tagnameUAProf = "x-wap-profile";
Ditto
Attachment #685949 -
Flags: review?(vyang) → review+
Updated•12 years ago
|
Keywords: dev-doc-needed
Assignee | ||
Comment 11•12 years ago
|
||
Fix indentations.
Attachment #685949 -
Attachment is obsolete: true
Assignee | ||
Updated•12 years ago
|
Keywords: checkin-needed
Comment 12•12 years ago
|
||
Keywords: checkin-needed
Comment 13•12 years ago
|
||
I've rebased attachment #686399 [details] [diff] [review] before pushing to inbound.
Comment 14•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Assignee | ||
Comment 15•12 years ago
|
||
Add some comments from vyang's email about UAProf.....
Please see below comments from vyang.
UAProf (User Agent Profile) is an OMA specification[1] concerning device
capabilities and preferences. In summary, a supporting device sends the
URL or full binary encoded profile to a remote server during some
protocol initiation process. Since different devices have different
harware/software profiles and preferences, there won't be a such profile
file in Firefox OS code base, but a configurable preference for the
device-maker hosted URL.
In MMS, the only place may relate to UAProf in Firefox OS, we've already
supported sending UAProf URL if Gecko pref "wap.UAProf.url" is set [2].
However, because MMS is not for v1.0, the patch was only landed in m-c
trunk and is not available in b2g18. Even we re-land it in b2g18, there
is no where that will trigger such profile url reporting. In Android,
UAProf URL is only used in the same scenario -- MMS. So, in my opinion,
we'll need more detailed items about what to do to support UAProfile on
a device that has no MMS.
[1]:
http://www.openmobilealliance.org/Technical/release_program/uap_v11.aspx
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=804754
Assignee | ||
Comment 16•12 years ago
|
||
For mms merge to b2g18.
Assignee | ||
Comment 17•12 years ago
|
||
Assignee | ||
Comment 19•12 years ago
|
||
Attachment #722016 -
Attachment is obsolete: true
Comment 20•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g18/rev/e8bc5e26c634
I know we're still waiting on leo+ for this but this blocks lots of other leo+ so I directly land this onto b2g18. This must be a leo+ for sure. We're asking Joe to help us to mark this.
status-b2g18:
--- → fixed
status-b2g18-v1.0.0:
--- → wontfix
status-b2g18-v1.0.1:
--- → wontfix
status-firefox20:
--- → fixed
Comment 21•12 years ago
|
||
this is reuqired for MMS in v1.1. Leo+
Updated•12 years ago
|
blocking-b2g: leo? → leo+
Comment 22•12 years ago
|
||
The entire set of clian's pushes was backed out for multiple reasons.
https://tbpl.mozilla.org/?tree=Mozilla-B2g18&rev=a0b06192f882
1.) The tree rules are clear that you are not to land on top of bustage. At the time you pushed, both B2G Mn and B2G xpcshell had bustage from prior commits that hadn't been backed out yet.
2.) The tree rules are also clear that you are to watch your pushes for any bustage and handle them accordingly. mozilla-inbound is the ONLY tree where this rule does not apply.
3.) Even after the earlier bustage was backed out, something in one of your many pushes was causing further B2G Mn failures as shown in the log below.
https://tbpl.mozilla.org/php/getParsedLog.php?id=20424173&tree=Mozilla-B2g18
4.) This isn't cause for backout by itself, but it is also strongly preferred to not push each commit individually as our build and testing resources are limited and doing so stretches them even thinner. Please limit your number of pushes as much as possible unless you have good reason for keeping them separate.
Comment 23•12 years ago
|
||
Updated•12 years ago
|
Blocks: mms-oma-compliance
Updated•12 years ago
|
Flags: in-moztrap-
You need to log in
before you can comment on or make changes to this bug.
Description
•