In a JNLP file, is the version property for a jar resource related to any metadata (e.g. manifest) or is it just arbitrarily set by the user creating the JNLP file?
Section 6 of the JNLP Specification gives the following information under section 6.3 "Version-based Download Protocol".
For the version-based download protocol, all resources are uniquely identified by a URL/version-id pair. Thus, a JNLP Client can at any given time request a specific version of a resource located at a specific URL.
The JNLP Client issues an HTTP GET request that includes the specific version of the resource that it needs. The request includes the field version-id, which specifies the requested version. For example, given the following jar element:
<jar href="http://www.mysite.com/b.jar" version="2.3+"/>
then the JNLP Client must issue the following HTTP GET request14:
http://www.mysite.com/c.jar?version-id=2.3%2B
The JNLP Client must examine the HTTP response status code and MIME type to determine if the result was successful. The valid responses are described in section 6.1.2. For the above jar element, the application/x-java-archive-diff MIME type cannot be returned. It can only be returned for incremental requests.
The version string used in the request is not necessarily exact, e.g., 2.3+. The Web server must specify the exact version-id of the resource that is returned in the response by setting the HTTP header field: x-java-jnlp-version-id. The exact version returned must be one that matches the requested version string.
Unfortunately the Spec. is not available for online browsing, but it can be downloaded. I have found it to be invaluable for JWS development.
Related
I'm trying to download a firmware.bin file that is produced in a private Github repository. I have the code that is finding the right asset url to download the file and per Github instructions the accept header needs to be set to accept: application/octet-stream in order to get the binary file. I'm only getting JSON in response. If I run the same request through postman I'm getting a binary file as the body. I've tried downloading it using HTTPClient and I get the same JSON request. It seems the headers aren't being set as requested to tell Github to send the binary content as I'm just getting JSON. As for the ArduinoOTA abstraction, I can't see how to even try to set headers and in digging into the esp_https_ota functions and http_client functions there doesn't appear to be a way to set headers for any of these higher level abstractions because the http_config object has no place for headers as far as I can tell. I might file a feature request to allow for this, but am new to this programming area and want to check to see if I'm missing something first.
Code returns JSON, not binary. URL is github rest api url to the asset (works in postman)
HTTPClient http2;
http2.setAuthorization(githubname,githubpass);
http2.addHeader("Authorization","token MYTOKEN");
http2.addHeader("accept","application/octet-stream");
http2.begin( firmwareURL, GHAPI_CERT); //Specify the URL and certificate
With the ESP IDF HTTP client you can add headers to an initialized HTTP client using function esp_http_client_set_header().
esp_http_client_handle_t client = esp_http_client_init(&config);
esp_http_client_set_header(client, "HeaderKey", "HeaderValue");
err = esp_http_client_perform(client);
If using the HTTPS OTA API, you can register for a callback which gives you a handle to the underlying HTTP client. You can then do the exact same as in above example.
I count 9 HTTP request methods (aka verbs):
GET
HEAD
POST
PUT
DELETE
CONNECT
OPTIONS
TRACE
PATCH
The above from: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
Is that it? will this ever change?
Registry
The HTTP 1.1 spec defines an Hypertext Transfer Protocol (HTTP) Method Registry. As of 2017-01, shows 39 entries:
ACL
BASELINE-CONTROL
BIND
CHECKIN
CHECKOUT
CONNECT
COPY
DELETE
GET
HEAD
LABEL
LINK
LOCK
MERGE
MKACTIVITY
MKCALENDAR
MKCOL
MKREDIRECTREF
MKWORKSPACE
MOVE
OPTIONS
ORDERPATCH
PATCH
POST
PRI
PROPFIND
PROPPATCH
PUT
REBIND
REPORT
SEARCH
TRACE
UNBIND
UNCHECKOUT
UNLINK
UNLOCK
UPDATE
UPDATEREDIRECTREF
VERSION-CONTROL
HTTP 1.0
HTTP 1.0 defined three methods (“verbs”):
GET… retrieve whatever information … is identified by the Request-URI…
POST… to request that the destination server accept
the entity enclosed in the request as a new subordinate of the
resource identified by the Request-URI in the Request-Line… Posting a message to a bulletin board, newsgroup, mailing list … Providing a block of data … Extending a database through an append operation …
HEAD… identical to GET except that the server MUST NOT
return a message-body in the response … for obtaining metainformation about the entity implied by the request without transferring the entity-body itself…
HTTP 1.1
HTTP 1.1 is officially defined in RFC 2068. This spec added five more methods.
OPTIONS…a request for information about the
communication options available on the request/response chain… determine the options and/or requirements associated with a resource,
or the capabilities of a server, without implying a resource action
or initiating a resource retrieval
PUT…requests that the enclosed entity be stored under the
supplied Request-URI. If … already
existing resource, the enclosed entity SHOULD be considered as a
modified version of the one residing on the origin server…
DELETE…delete the resource
identified by the Request-URI…
TRACE…loop-
back of the request message…
CONNECT…for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling…
HTTP Extensions
Other protocols extend HTTP to define additional methods/verbs.
PATCH
Applies partial modifications to a resource
Defined by RFC 5789
WebDAV specifies seven more methods:
PROPFIND
PROPPATCH
MKCOL
COPY
MOVE
LOCK
UNLOCK
HTTP/2
HTTP/2 is defined in RFC 7540. Section 3.5 defines a PRI method.
PRIIn HTTP/2, each endpoint is required to send a connection preface as a final confirmation of the protocol in use and to establish the initial settings for the HTTP/2 connection. … the connection preface starts with the string "PRI *
HTTP/2.0\r\n\r\nSM\r\n\r\n") …
Prognostication
will this ever change?
Not likely.
Given the wide use of Web RPC and SOAP, and now the rising popularity of RESTful services bringing new life to the existing basic verbs, there is little need to devise new verbs at the HTTP level. Where people need their own domain-specific meaningful verbs, they can embed within the message being delivered via HTTP.
I expect we’ll not see more HTTP methods become popular any time soon.
See the spec:
"Additional methods, outside the scope of this specification, have been standardized for use in HTTP. All such methods ought to be registered within the "Hypertext Transfer Protocol (HTTP) Method Registry" maintained by IANA, as defined in Section 8.1." -- https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.4.1.p.7>
And the IANA registry contains many more.
According to WebDAV specification (RFC 4918):
The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is
identified by the Request-URI" [RFC2616].
and PROPFIND
retrieves properties defined on the resource identified by the Request-URI.
So GET and PROPFIND more or less retrieve the information of a resource. In this sense, is there any major difference between GET and PROPFIND and when should one be used instead of the other.
The very paragraph, you refer to, explains it:
GET, when applied to a collection, may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether.
I.e. the GET behaves as it historically did, to maintain a backward compatibility. It will typically return an "index" page (file index.html, index.php or similar) or it will automatically render an HTML page with a directory contents (a file list). This means the WebDAV server can run on the same port as HTTP server (= as an extension of the HTTP server), with the existing HTTP requests behaving the same.
While the WebDAV PROPFIND request will return an exactly defined, machine-readable, XML document, according to the WebDAV specification.
If you are implementing a WebDAV client or server, you are interested in the PROPFIND only. A GET response does not have a defined format (not even content), so it cannot be parsed by an application.
WebDAV PROPFIND method is used to retrieve properties of the resource mentioned by the URI.
HTTP GET method can return the produced data and not the source text of resource, in case if it is pointed to a data producing resource. Refer the below text from RFC 2616 - Hypertext Transfer Protocol.
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process. Source - RFC 2616
When a user clicks a link to a drawing on my site http://mysite.com/some-drawing,
I would like my server to respond with status code 300 and two resource locations: http://mysite.com/some-drawing.png and http://mysite.com/some-drawing.myapp, and have the client browser decide automatically which one to use, based on its capabilities:
If MyApp is installed on the user's machine, then the browser should download the *.myapp version and use MyApp to display it.
However, if MyApp is not installed, and the browser is incapable to display this version, then I would like it to pick the *.png version.
However, I am having a hard time figuring out the structure of a HTTP response with status code 300.
The rfc2616 says:
The requested resource corresponds to any one of a set of
representations, each with its own specific location, and agent-
driven negotiation information (section 12) is being provided so that
the user (or user agent) can select a preferred representation and
redirect its request to that location.
Unless it was a HEAD request, the response SHOULD include an entity
containing a list of resource characteristics and location(s) from
which the user or user agent can choose the one most appropriate. The
entity format is specified by the media type given in the Content-
Type header field. Depending upon the format and the capabilities of
the user agent, selection of the most appropriate choice MAY be
performed automatically. However, this specification does not define
any standard for such automatic selection.
If the server has a preferred choice of representation, it SHOULD
include the specific URI for that representation in the Location
field; user agents MAY use the Location field value for automatic
redirection. This response is cacheable unless indicated otherwise.
The wording "entity containing a list of resource characteristics and location(s)" seems ambiguous. What does it mean? Does anybody know how this is done?
That won't work.
The "multiple choices" are done by sending the links in hypertext (HTML) content and let the user pick.
In theory, if a client supported server-driven negotiation, you could send back various 'Accept-*' headers, but those are rather limited (eg, Languauge, Encoding, Charset), and could be used for 'do you want the PDF or MS Word document?' or 'Would you like that in Spanish or English?'), but not for other arbitrary distinctions. I'm not aware of any browsers that support it. Instead, they have the browser send the Accept headers, and the server respond with whatever it thinks is best.
See :
RFC 2295, "Transparent Content Negotiation in HTTP"
RFC 2616, "HTTP/1.1" section 12 "Content Negotiation" (for problems related to server-driven content negotiation)
update :
Also see Mozilla Developer Network's "Content negotiation", which discusses some advantage and disadvantages of server-drive vs. client-driven negotiation, and some additional headers that may be of interest (eg, looking to see if the client sends 'Negotiate' to announce what it supports)
Meaning will it work fine? I have a situation where I am attaching files via HTTP attachment by attaching the URI of the file and it is on a different server so I don't have access to the length of the file.
It will work fine. The client will just read to EOF. The client only won't be able to calculate/estimate the progress of download.
It may work fine but the HTTP spec states that applications SHOULD send the length if it's possible to determine:
Applications SHOULD use this field to
indicate the transfer-length of the
message-body, unless this is
prohibited by the rules in section
4.4.
Any Content-Length greater than or
equal to zero is a valid value.
Section 4.4 describes how to determine
the length of a message-body if a
Content-Length is not given.
Note that the meaning of this field is
significantly different from the
corresponding definition in MIME,
where it is an optional field used
within the "message/external-body"
content-type. In HTTP, it SHOULD be
sent whenever the message's length can
be determined prior to being
transferred, unless this is prohibited
by the rules in section 4.4.