DAP4: DAP4 Using Multi-part Mime: Difference between revisions
From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
(Created page with "DevelopmentDAP4 << Back to OPULS Development ==Background== After thinking about it as a result of a comment in...") |
No edit summary |
||
| Line 3: | Line 3: | ||
==Background== | ==Background== | ||
As a result of a comment | |||
in the OPULS/NOAA telecon, I think we should | in the OPULS/NOAA telecon, I think we should | ||
reconsider using multi-part mime in a limited fashion | reconsider using multi-part mime in a limited fashion | ||
in our serialization. | in our serialization. Basically I propose to resurrect | ||
James' original proposal (see [[DAP 4.0 Design]]). | |||
== | ==Proposal== | ||
The | As with the original proposal, the multipart-mime | ||
has two parts. The first is for the DMR and the | |||
second is for the whole, chunked serialized data. | |||
The general form would look something like this. | |||
<pre> | |||
Content-Type: multipart/related; \ | |||
type="application/vnd.org.opendap.dap4.dataset-metadata+xml"; \ | |||
start="<<start id>>"; boundary="<<boundary>>" | |||
--<<boundary>> | |||
Content-Type: text/xml; charset=UTF-8 | |||
Content-Id: <<start id>> | |||
Content-Length: ddddd | |||
<<blank line>> | |||
<<DMR text>> | |||
--<<boundary>> | |||
Content-Type: application/octet-stream | |||
Content-Encoding: big-endian | |||
Content-Length: -1 | |||
<<blank-line> | |||
<<chunked representation of the serialized data>> | |||
--<<boundary>> | |||
</pre> | |||
Notes: | |||
# Every header line should be terminated with CRLF. The <<blankline>> is also terminated with CRLF. | |||
of the | # The above representation assumes that the DMR is not in chunked format. | ||
# The Content-Length value for the DMR counts the number of UTF-8 characters from the end of the blank line to the initial "--" of the boundary line. | |||
# The chunked representation is still in our existing chunked format. | |||
# I do not know if the start-id is required by the multipart-mime format. If not, then we should remove it. | |||
# I am not sure about the "type" param of the "Content-Type" line at the beginning. | |||
[[User:dmh|Dennis Heimbigner]] Initial draft 3/19/2013 | |||
Latest revision as of 18:19, 20 March 2013
Background
As a result of a comment in the OPULS/NOAA telecon, I think we should reconsider using multi-part mime in a limited fashion in our serialization. Basically I propose to resurrect James' original proposal (see DAP 4.0 Design).
Proposal
As with the original proposal, the multipart-mime has two parts. The first is for the DMR and the second is for the whole, chunked serialized data. The general form would look something like this.
Content-Type: multipart/related; \
type="application/vnd.org.opendap.dap4.dataset-metadata+xml"; \
start="<<start id>>"; boundary="<<boundary>>"
--<<boundary>>
Content-Type: text/xml; charset=UTF-8
Content-Id: <<start id>>
Content-Length: ddddd
<<blank line>>
<<DMR text>>
--<<boundary>>
Content-Type: application/octet-stream
Content-Encoding: big-endian
Content-Length: -1
<<blank-line>
<<chunked representation of the serialized data>>
--<<boundary>>
Notes:
- Every header line should be terminated with CRLF. The <<blankline>> is also terminated with CRLF.
- The above representation assumes that the DMR is not in chunked format.
- The Content-Length value for the DMR counts the number of UTF-8 characters from the end of the blank line to the initial "--" of the boundary line.
- The chunked representation is still in our existing chunked format.
- I do not know if the start-id is required by the multipart-mime format. If not, then we should remove it.
- I am not sure about the "type" param of the "Content-Type" line at the beginning.
Dennis Heimbigner Initial draft 3/19/2013
