Implement `Server`, `ETag`, `Last-Modified` and `Cache-Control` headers on #37

davidjwbbc · 2023-02-01T11:17:01Z

Specification

`Server` header

All 5GMS Application Function responses (including error responses) must have a Server header (section 10.2.4 of RFC 9110) which conforms to the format 5GMSdAF-{FQDN}/{implementationSpecificSuffix} (see TS 26.512 clause 6.2.3.3.1) where:

{FQDN} is the fully qualified domain name of the Application Function host.
{implementationSpecificSuffix} shall identify at least the 3GPP release number (e.g. 17), and preferably the version number of TS 26.512 that the Application Function is implementing (e.g. 17.3.0).
- This value shall be populated from a macro set in the top-level meson.build file.

A comment shall be appended to the primary product string indicating the YAML OpenAPI specification API name and version number with which the API complies (e.g. info.title=M1_ContentHostingProvisioning;info.version=2.1.1). This string shall be derived from the info.title and info.version properties of the relevant YAML OpenAPI definition, preferably by introspecting the code generated by OpenAPI Generator. Note that the value may be different for each API in a given version of TS 26.512.

In addition, the reference implementation shall provide a vendor-specific subproduct string indicating the name rt-5gms-application-function followed by an oblique character followed by the release number of the Application Function (e.g. 1.1.0). The latter shall be populated from a macro set in the top-level meson.build file.

Complete example:

Server: 5GMSdAF-msaf1.mno.net/17.3.0 (info.title=M1_ContentHostingProvisioning;info.version=2.1.1) rt-5gms-application-function/1.1.0

Entity headers

Additionally all 2XX server responses that contain body data must also have ETag, Last-Modified and Cache-Control headers (see TS 26.512 clause 6.2.3.4).

These extra headers shall appear on both M1 and M5 interfaces.

Scope of applicability

This currently means the following API operations will contain the extra ETag, Last-Modified and Cache-Control headers:

M1
- createProvisioningSession (Implement M1 Provisioning Session #15)
- getProvisioningSessionById (Implement M1 Provisioning Session #15)
- createContentHostingConfiguration (Implement M1 Content Hosting Provisioning API #18)
- retrieveContentHostingConfiguration (Implement M1 Content Hosting Provisioning API #18)
- createOrReserveServerCertificate (Implement M1 Server Certificates Provisioning API #17)
- retrieveServerCertificate (Implement M1 Server Certificates Provisioning API #17)
- retrieveContentProtocols (Implement M1 Content Protocols Discovery API #16)
M5
- retrieveServiceAccessInformation (Expose ServiceAccessInformation at M5d #6)

`Etag` header

Where possible, the ETag shall be a SHA256 hash of the underlying entity served by the Application Function, encoded as a hexadecimal string.

In the case of Server Certificates, the entity tag value is provided by the external certificate management process and therefore may not be a SHA256.

`Last-Modified` header

The Last-Modified date-time shall be output in IMF format ("Day, dd Mon YYYY HH:MM:SS GMT") as defined in RFC 7231. This will be the date-time of when the last create or update operation was received that created or modified the object being returned.

In the case of Server Certificates, the last modified date-time value is provided by the external certificate management process.

`Cache-Control` header

The Cache-Control header shall indicate a max-age based on defaults that can be changed in the application YAML configuration file. The default max-age shall be 60 seconds, except for M1 Content Protocols responses which shall use a default of 86400 seconds (because the information in the response is static for a given 5GMS AF build).

The configuration file shall allow the main default to be changed and also individual override values for max-age for M1 Provisioning Sessions, M1 Content Hosting Configurations, M1 Content Protocols and M5 Service Access Information, which take preference over the default max-age for those responses.
The Cache-Control header for M1 Server Certificates is provided by the external certificate management process.
- If absent from the certificate management process output then the current Application Function default shall be used.

The text was updated successfully, but these errors were encountered:

rjb1000 · 2023-02-01T12:31:49Z

Is the intention here to support these response headers for both HTTP/1.1 and HTTP/2, @davidjwbbc? (That's not clear from the above specification yet.)

rjb1000 · 2023-02-01T12:56:57Z

Thinking about the {implementationSpecificSuffix} of the Server header, I am wondering whether TS 26.512 clause 6.2.3.3.1 is as good as it could be. I reckon it would be more useful to an M1 or M5 client to know which version of the specification the Application Function complies with. It might be difficult for implementations to be precise about this (e.g. if they have cherry-picked features from different versions), but it would at least be useful to know the 3GPP release number in the Server header, e.g.

Server: 5GMSdAF-msaf1.mno.net/17

If this seems like a reasonable idea I might propose a small change to this clause along those lines in the forthcoming SA4#122 meeting.

Reading section 10.2.4 of RFC 9110 I see that there can be an arbitrary number of product identifiers in the header value, separated by whitespace. It seems more appropriate for us to create a vendor-specific product identifier to convey our release number. For example:

Server: 5GMSdAF-msaf1.mno.net/17 rt-5gms-application-function/1.1.0

rjb1000 · 2023-02-01T13:04:08Z

Also (and of potential interest to @irajs) I notice there is nothing to specify what the 5GMSu AF should use as a Server header! Uplink streaming is in the process of being fleshed out a bit more by him in Rel-18. However, given that Iraj has proposed provisioning downlink and uplink streaming via a common M1 API, I'm not entirely convinced that it's necessary to distinguish a 5GMSd AF from a 5GMSu AF, especially since a single 5GMS AF could be managing both downlink and uplink media streaming in a deployed 5GMS System. Given this, maybe the correct course of action is to simplify the current specification by making the primary product string 5GMSAF-{FQDN}/{Release}

davidjwbbc · 2023-02-01T16:06:27Z

You can also add comments, so it's valid for us to include the software name and version as a comment to the server id, e.g.:

Server: 5GMSdAF-msaf1.mno.net/17.3.0 (rt-5gms-application-function/1.1.0)

Alternatively it could be useful to use the comment to list the protocol version numbers implemented, e.g.:

Server: 5GMSdAF-msaf1.mno.net/rt-5gms-application-function-1.1.0 (m1=17.3.0;m5=17.2.0)

davidjwbbc · 2023-02-01T16:09:41Z

Is the intention here to support these response headers for both HTTP/1.1 and HTTP/2, @davidjwbbc? (That's not clear from the above specification yet.)

Yes, the headers belong on the response no matter which version of the HTTP protocol is being used. Although the field names will get converted to lowercase in the HTTP/2 protocol so will be server, etag, last-modified and cache-control. But this should happen automatically.

The SBI library abstracts the protocol version away from the response structure, so when we build a response we don't care whether it's HTTP/1.1 or HTTP/2.

For now the 5GMS AF only does HTTP/1.1 until we implement issue #12.

rjb1000 · 2023-02-02T12:02:28Z

I have updated the specification of the Server header at the top of the issue based on discussion.

In particular, I have simplified the specification of the comment part to indicate only the OpenAPI version number for the endpoint that has been invoked. (I think it's not good practice to expose details of M5 at M1 and vice versa.) Ideally, this value can be derived by inspecting the code that OpenAPI Generator has autogenerated from the OpenAPI YAML file. (The API version number appears as info.version in those files.) I have also proposed including the API name from the YAML file (which appears as info.title). If these are not readily available to the running code, we can think again.

rjb1000 · 2023-02-02T13:19:24Z

In particular, I have simplified the specification of the comment part to indicate only the OpenAPI version number for the endpoint that has been invoked. (I think it's not good practice to expose details of M5 at M1 and vice versa.) Ideally, this value can be derived by inspecting the code that OpenAPI Generator has autogenerated from the OpenAPI YAML file. (The API version number appears as info.version in those files.) I have also proposed including the API name from the YAML file (which appears as info.title). If these are not readily available to the running code, we can think again.

To explain my rationale here a bit: I think the API version number is more critical than the specification version number. It's finer grained, and also the key information a client needs to understand for compatibility.

rjb1000 · 2023-02-02T13:21:51Z

To expose more information about what APIs the reference implementation of the 5GMS AF currently supports, and which subset of methods each API currently implements, I have created a new issue #38 to implement the OPTIONS method at reference point M1.

rjb1000 · 2023-02-02T14:35:19Z

I have raised 5G-MAG/Standards#50 to propose an amendment to TS 26.512 clause 6.2.3.3.1 regarding the Server header. (It doesn't block implementation of the specification on this issue.)

davidjwbbc · 2023-02-02T16:59:21Z

For Last-Modified if you're using the strftime() system function to format the time then set TZ environment variable to "GMT", LC_TIME environment variable to "C" and use the format "%a, %d %b %Y %H:%M:%S %Z".

rjb1000 · 2023-02-02T17:47:01Z

set TZ environment variable to "GMT", LC_TIME environment variable to "en_US"

I assume you mean set these environment variables in the main function of the Application Function (as opposed to setting them on the command line), @davidjwbbc?

Is there a reason you recommend GMT as the time zone rather than UTC? (I believe the two have different rules for handling leap seconds.)

Also, is there a particular reason to use the en_US locale in preference to the POSIX default locale C?

davidjwbbc · 2023-02-03T10:04:46Z

set TZ environment variable to "GMT", LC_TIME environment variable to "en_US"

I assume you mean set these environment variables in the main function of the Application Function (as opposed to setting them on the command line), @davidjwbbc?

They need to be set at some time before strftime() is called, the best place is probably in the 5GMS Application Function start-up.

Is there a reason you recommend GMT as the time zone rather than UTC? (I believe the two have different rules for handling leap seconds.)

Yes, because using UTC would generate date-time strings in the wrong timezone. The RFC 7231 IMF format says that the date-time must always be in GMT, so the timezone needs to be GMT.

$ TZ=UTC date +'%a, %d %b %Y %H:%M:%S %Z'; TZ=GMT  date +'%a, %d %b %Y %H:%M:%S %Z'
Fri, 03 Feb 2023 09:49:22 UTC
Fri, 03 Feb 2023 09:49:22 GMT

As you can see, if the timezone is UTC then the date-time gets UTC appended, but gets the correct zone with GMT.

Also, is there a particular reason to use the en_US locale in preference to the POSIX default locale C?

Because the names in the RFC were in English, but the C locale would probably be better as that also uses the English names but is more cross platform. [I've edited my comment above to change the LC_TIME value to C instead]

devbbc · 2023-02-07T09:42:56Z

Implemented custom nf_server_new_response function. The headers Server, ETag, Last-Modified and Cache-Control are set when a response is created.

The M1 and M5 responses mentioned above need to be created with this function instead of the default ogs_sbi_response_new.

As a next step, will be replacing the default response creation function with the custom one.

The Last-Modified header sets time in GMT as seen in the sample header output:

...
 Content-Length: 636
< Cache-Control: 60
< Last-Modified: Tue, 07 Feb 2023 10:53:47 GMT
< ETag: 1f05ec542503481e293beb2d824903b08f146264c9ae9d5e47b399dde94ffa1e
< Content-Type: application/json
< Location: /3gpp-m1/v2/provisioning-sessions/a98a09ca-a6d5-41ed-8b6c-edeafa546a93/content-hosting-configuration
< Server: 5GMSdAF-af.localdomain/17.3.0 (info.title=M1_ContentHostingProvisioning;info.version=2.1.0) rt-5gms-application-function/1.1.0
...

davidjwbbc · 2023-02-08T11:41:17Z

Regarding the environment variables for date-time formatting, the following should be placed near the top of the app_initialize() function to ensure all date-time outputs from the Application Function are in GMT:

ogs_env_set("TZ", "GMT");
ogs_env_set("LC_TIME", "C");

(Note that ogs_env_set() is designed as a cross-platform solution for setting in-process environment variables.)

devbbc · 2023-02-09T07:07:21Z

The success responses for the operations createProvisioningSession, getProvisioningSessionById, createContentHostingConfiguration and retrieveContentHostingConfiguration now have the ETag, Last-Modified and Cache-Control response headers set, as well as the specified Server header.
All error responses have now the Server response header.

Next, I am going to implement the M5 - retrieveServiceAccessInformation followed by the Server Certificate APIs mentioned above.

Sample output below.

`createProvisioningSession`

$ curl -H 'User-Agent: AF' -H 'Content-Type: application/json' --data @/home/ubuntu/ps.json -v http://127.0.0.22:7777/3gpp-m1/v2/provisioning-sessions
*   Trying 127.0.0.22:7777...
* TCP_NODELAY set
* Connected to 127.0.0.22 (127.0.0.22) port 7777 (#0)
> POST /3gpp-m1/v2/provisioning-sessions HTTP/1.1
> Host: 127.0.0.22:7777
> Accept: */*
> User-Agent: AF
> Content-Type: application/json
> Content-Length: 118
> 
* upload completely sent off: 118 out of 118 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 201 Created
< Connection: Keep-Alive
< Content-Length: 179
< Cache-Control: 62
< Last-Modified: Thu, 09 Feb 2023 11:37:49 GMT
< ETag: 341e6fc1a763ebc1f533af7bb82c40f36a5c11b3a554a379e8fd3e90aa895690
< Content-Type: application/json
< Location: /3gpp-m1/v2/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362a6
< Server: 5GMSdAF-af.localdomain/17.3.0 (info.title=M1_ProvisioningSessions; info.version=2.0.0) rt-5gms-application-function/1.1.0
< Date: Thu, 09 Feb 2023 11:37:49 GMT
< 
{
	"provisioningSessionId":	"2e6a9030-a86e-41ed-89a1-b1ed416362a6",
	"provisioningSessionType":	"DOWNLINK",
	"aspId":	"BBC",
	"externalApplicationId":	"Media Streaming Downlink"
* Connection #0 to host 127.0.0.22 left intact
}

`getProvisioningSession`

$ curl  -H 'User-Agent: AF' -v http://127.0.0.22:7777/3gpp-m1/v2/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362a6
*   Trying 127.0.0.22:7777...
* TCP_NODELAY set
* Connected to 127.0.0.22 (127.0.0.22) port 7777 (#0)
> GET /3gpp-m1/v2/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362a6 HTTP/1.1
> Host: 127.0.0.22:7777
> Accept: */*
> User-Agent: AF
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Connection: Keep-Alive
< Content-Length: 179
< Content-Type: application/json
< Server: 5GMSdAF-af.localdomain/17.3.0 (info.title=M1_ProvisioningSessions; info.version=2.0.0) rt-5gms-application-function/1.1.0
< Cache-Control: 62
< Last-Modified: Thu, 09 Feb 2023 11:37:49 GMT
< ETag: 341e6fc1a763ebc1f533af7bb82c40f36a5c11b3a554a379e8fd3e90aa895690
< Date: Thu, 09 Feb 2023 11:43:14 GMT
< 
{
	"provisioningSessionId":	"2e6a9030-a86e-41ed-89a1-b1ed416362a6",
	"provisioningSessionType":	"DOWNLINK",
	"aspId":	"BBC",
	"externalApplicationId":	"Media Streaming Downlink"
* Connection #0 to host 127.0.0.22 left intact
}

`createContentHostingConfiguration`

$ curl  -H 'User-Agent: AF' -H 'Content-Type: application/json' --data @/home/ubuntu/git0-2912/rt-5gms-application-function/examples/ContentHostingConfiguration_Big-Buck-Bunny_pull-ingest_http_and_https.json -v http://127.0.0.22:7777/3gpp-m1/v2/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362a6/content-hosting-configuration
*   Trying 127.0.0.22:7777...
* TCP_NODELAY set
* Connected to 127.0.0.22 (127.0.0.22) port 7777 (#0)
> POST /3gpp-m1/v2/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362a6/content-hosting-configuration HTTP/1.1
> Host: 127.0.0.22:7777
> Accept: */*
> User-Agent: AF
> Content-Type: application/json
> Content-Length: 375
> 
* upload completely sent off: 375 out of 375 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 201 Created
< Connection: Keep-Alive
< Content-Length: 636
< ETag: 323e82a5607d848be73319459bdf3dde64093a3a58d4adf0ba886cf7d7f6855e
< Content-Type: application/json
< Location: /3gpp-m1/v2/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362a6/content-hosting-configuration
< Server: 5GMSdAF-af.localdomain/17.3.0 (info.title=M1_ContentHostingProvisioning; info.version=2.1.0) rt-5gms-application-function/1.1.0
< Cache-Control: 63
< Last-Modified: Thu, 09 Feb 2023 11:38:10 GMT
< Date: Thu, 09 Feb 2023 11:38:10 GMT
< 
{
   "distributionConfigurations":	[{
   		"baseURL":	"http://localhost/m4d/provisioning-session-2e6a9030-a86e-41ed-89a1-b1ed416362a6/",
   		"canonicalDomainName":	"localhost"
   	}, {
   		"baseURL":	"https://localhost/m4d/provisioning-session-2e6a9030-a86e-41ed-89a1-b1ed416362a6/",
   		"canonicalDomainName":	"localhost",
   		"certificateId":	"testcert1"
   	}],
   "entryPointPath":	"BigBuckBunny_4s_onDemand_2014_05_08.mpd",
   "ingestConfiguration":	{
   	"baseURL":	"https://ftp.itec.aau.at/datasets/DASHDataset2014/BigBuckBunny/4sec/",
   	"protocol":	"urn:3gpp:5gms:content-protocol:http-pull-ingest",
   	"pull":	true
   },
   "name":	"Big Buck Bunny"
* Connection #0 to host 127.0.0.22 left intact
}

`retrieveContentHostingConfiguration`

$ curl  -H 'User-Agent: AF' -v http://127.0.0.22:7777/3gpp-m1/v2/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362a6/content-hosting-configuration
*   Trying 127.0.0.22:7777...
* TCP_NODELAY set
* Connected to 127.0.0.22 (127.0.0.22) port 7777 (#0)
> GET /3gpp-m1/v2/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362a6/content-hosting-configuration HTTP/1.1
> Host: 127.0.0.22:7777
> Accept: */*
> User-Agent: AF
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Connection: Keep-Alive
< Content-Length: 636
< Cache-Control: 63
< Last-Modified: Thu, 09 Feb 2023 11:38:10 GMT
< ETag: 323e82a5607d848be73319459bdf3dde64093a3a58d4adf0ba886cf7d7f6855e
< Content-Type: application/json
< Location: /3gpp-m1/v2/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362a6/content-hosting-configuration
< Server: 5GMSdAF-af.localdomain/17.3.0 (info.title=M1_ContentHostingProvisioning; info.version=2.1.0) rt-5gms-application-function/1.1.0
< Date: Thu, 09 Feb 2023 11:40:57 GMT
< 
{
	"distributionConfigurations":	[{
			"baseURL":	"http://localhost/m4d/provisioning-session-2e6a9030-a86e-41ed-89a1-b1ed416362a6/",
			"canonicalDomainName":	"localhost"
		}, {
			"baseURL":	"https://localhost/m4d/provisioning-session-2e6a9030-a86e-41ed-89a1-b1ed416362a6/",
			"canonicalDomainName":	"localhost",
			"certificateId":	"testcert1"
		}],
	"entryPointPath":	"BigBuckBunny_4s_onDemand_2014_05_08.mpd",
	"ingestConfiguration":	{
		"baseURL":	"https://ftp.itec.aau.at/datasets/DASHDataset2014/BigBuckBunny/4sec/",
		"protocol":	"urn:3gpp:5gms:content-protocol:http-pull-ingest",
		"pull":	true
	},
	"name":	"Big Buck Bunny"
* Connection #0 to host 127.0.0.22 left intact
}

Error message

$ curl  -H 'User-Agent: AF' -v http://127.0.0.22:7777/3gpp-m1/v2/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362/content-hosting-configuration
*   Trying 127.0.0.22:7777...
* TCP_NODELAY set
* Connected to 127.0.0.22 (127.0.0.22) port 7777 (#0)
> GET /3gpp-m1/v2/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362/content-hosting-configuration HTTP/1.1
> Host: 127.0.0.22:7777
> Accept: */*
> User-Agent: AF
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Connection: Keep-Alive
< Content-Length: 284
< Content-Type: application/problem+json
< Server: 5GMSdAF-af.localdomain/17.3.0 rt-5gms-application-function/1.1.0
< Date: Thu, 09 Feb 2023 11:45:33 GMT
< 
{
	"type":	"/3gpp-m1/v2",
	"title":	"Provisioning session does not exist.",
	"status":	404,
	"detail":	"Provisioning Session [2e6a9030-a86e-41ed-89a1-b1ed416362] does not exist.",
	"instance":	"/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362/content-hosting-configuration"
* Connection #0 to host 127.0.0.22 left intact
}

davidjwbbc · 2023-02-09T14:36:39Z

...

`createProvisioningSession`

$ curl -H 'User-Agent: AF' -H 'Content-Type: application/json' --data @/home/ubuntu/ps.json -v http://127.0.0.22:7777/3gpp-m1/v2/provisioning-sessions
...
< HTTP/1.1 201 Created
< Connection: Keep-Alive
< Content-Length: 179
< Cache-Control: 62
< Last-Modified: Thu, 09 Feb 2023 11:37:49 GMT
< ETag: 341e6fc1a763ebc1f533af7bb82c40f36a5c11b3a554a379e8fd3e90aa895690
< Content-Type: application/json
< Location: /3gpp-m1/v2/provisioning-sessions/2e6a9030-a86e-41ed-89a1-b1ed416362a6
< Server: 5GMSdAF-af.localdomain/17.3.0 (info.title=M1_ProvisioningSessions; info.version=2.0.0) rt-5gms-application-function/1.1.0
< Date: Thu, 09 Feb 2023 11:37:49 GMT
< 
...

The correct format for the Cache-Control header would be:

Cache-Control: max-age=62

devbbc · 2023-02-13T08:30:38Z

Implemented the custom header for retrieveServiceAccessInformation. A sample output is shown below:

$ curl -v http://127.0.0.22:7777/3gpp-m5/v2/service-access-information/3d11bbe8-a960-41ed-986f-07bd7abbd7eb
*   Trying 127.0.0.22:7777...
* TCP_NODELAY set
* Connected to 127.0.0.22 (127.0.0.22) port 7777 (#0)
> GET /3gpp-m5/v2/service-access-information/3d11bbe8-a960-41ed-986f-07bd7abbd7eb HTTP/1.1
> Host: 127.0.0.22:7777
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 201 Created
< Connection: Keep-Alive
< Content-Length: 278
< Content-Type: application/json
< Cache-Control: max-age=: 64
< Server: 5GMSdAF-af.localdomain/17.3.0 (info.title=M5_ServiceAccessInformation; info.version=2.1.0) rt-5gms-application-function/1.1.0
< Last-Modified: Fri, 10 Feb 2023 16:31:30 GMT
< ETag: 8caf389eb3789b1b1ce1b57377bc56f92714aa2485e194d854c6c2c9a96381f0
< Date: Fri, 10 Feb 2023 16:31:48 GMT
< 
{
	"provisioningSessionId":	"3d11bbe8-a960-41ed-986f-07bd7abbd7eb",
	"provisioningSessionType":	"DOWNLINK",
	"streamingAccess":	{
		"mediaPlayerEntry":	"https://localhost/m4d/provisioning-session-3d11bbe8-a960-41ed-986f-07bd7abbd7eb/BigBuckBunny_4s_onDemand_2014_05_08.mpd"
	}
* Connection #0 to host 127.0.0.22 left intact
}

In this output : in max-age=: is added by the underlying server and not by the Application Function.

rjb1000 · 2023-02-13T09:37:36Z

In this output : in max-age=: is added by the underlying server and not by the Application Function.

Weird. Maybe you're using the API in a way that is different from envisaged, @devbbc?

davidjwbbc · 2023-02-13T10:00:26Z

Yes, @devbbc had added the "max-age=" bit to the header name instead of the value.

I've pointed out where in the code this is wrong in a separate email.

devbbc · 2023-02-13T10:48:04Z

Set the max-age= as part of the value instead of header name and that now the output is in the required format.

$ curl -v http://127.0.0.22:7777/3gpp-m5/v2/service-access-information/18d97126-ab8b-41ed-90cb-9fccaa7b26f3
*   Trying 127.0.0.22:7777...
* TCP_NODELAY set
* Connected to 127.0.0.22 (127.0.0.22) port 7777 (#0)
> GET /3gpp-m5/v2/service-access-information/18d97126-ab8b-41ed-90cb-9fccaa7b26f3 HTTP/1.1
> Host: 127.0.0.22:7777
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 201 Created
< Connection: Keep-Alive
< Content-Length: 278
< Cache-Control: max-age=64
< Last-Modified: Mon, 13 Feb 2023 10:43:49 GMT
< ETag: f9cd5233a5ea08f0796f3e5dc0cc891f873a90d0750244cea754e7a5d361e75f
< Content-Type: application/json
< Server: 5GMSdAF-af.localdomain/17.3.0 (info.title=M5_ServiceAccessInformation; info.version=2.1.0) rt-5gms-application-function/1.1.0
< Date: Mon, 13 Feb 2023 10:44:45 GMT
< 
{
	"provisioningSessionId":	"18d97126-ab8b-41ed-90cb-9fccaa7b26f3",
	"provisioningSessionType":	"DOWNLINK",
	"streamingAccess":	{
		"mediaPlayerEntry":	"https://localhost/m4d/provisioning-session-18d97126-ab8b-41ed-90cb-9fccaa7b26f3/BigBuckBunny_4s_onDemand_2014_05_08.mpd"
	}
* Connection #0 to host 127.0.0.22 left intact
}

The next step is to add custom headers for Server Certificate operations mentioned above.

devbbc · 2023-02-13T11:34:26Z

Discussed internally and decided to implement headers on the Server Certificates and content Protocols as part of #17 and #16 respectively.

davidjwbbc added the enhancement New feature or request label Feb 1, 2023

davidjwbbc added this to the MWC23 milestone Feb 1, 2023

davidjwbbc assigned devbbc Feb 1, 2023

davidjwbbc added this to 5GMS: M1d Provisioning Feb 1, 2023

davidjwbbc mentioned this issue Feb 1, 2023

Implement M1 Content Hosting Provisioning API #18

Closed

davidjwbbc moved this to In Progress in 5GMS: M1d Provisioning Feb 1, 2023

rjb1000 mentioned this issue Feb 2, 2023

Implement OPTIONS method for M1 API endpoints #38

Open

rjb1000 mentioned this issue Feb 2, 2023

Improve specification of 5GMS AF server identification 5G-MAG/Standards#50

Closed

rjb1000 moved this from In Progress to Ready for review in 5GMS: M1d Provisioning Feb 13, 2023

davidjwbbc self-assigned this Feb 13, 2023

davidjwbbc mentioned this issue Feb 13, 2023

Implement M1 Content Protocols Discovery API #16

Closed

devbbc mentioned this issue Feb 14, 2023

Implement M1 Server Certificates Provisioning API #17

Closed

devbbc moved this from Ready for review to Done in 5GMS: M1d Provisioning Feb 24, 2023

davidjwbbc closed this as completed Aug 1, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement `Server`, `ETag`, `Last-Modified` and `Cache-Control` headers on #37

Implement `Server`, `ETag`, `Last-Modified` and `Cache-Control` headers on #37

davidjwbbc commented Feb 1, 2023 •

edited by rjb1000

Loading

rjb1000 commented Feb 1, 2023

rjb1000 commented Feb 1, 2023 •

edited

Loading

rjb1000 commented Feb 1, 2023

davidjwbbc commented Feb 1, 2023 •

edited

Loading

davidjwbbc commented Feb 1, 2023 •

edited

Loading

rjb1000 commented Feb 2, 2023 •

edited

Loading

rjb1000 commented Feb 2, 2023

rjb1000 commented Feb 2, 2023

rjb1000 commented Feb 2, 2023

davidjwbbc commented Feb 2, 2023 •

edited

Loading

rjb1000 commented Feb 2, 2023 •

edited

Loading

davidjwbbc commented Feb 3, 2023 •

edited

Loading

devbbc commented Feb 7, 2023 •

edited

Loading

davidjwbbc commented Feb 8, 2023 •

edited by rjb1000

Loading

devbbc commented Feb 9, 2023 •

edited

Loading

davidjwbbc commented Feb 9, 2023 •

edited

Loading

`createProvisioningSession`

devbbc commented Feb 13, 2023 •

edited

Loading

rjb1000 commented Feb 13, 2023 •

edited

Loading

davidjwbbc commented Feb 13, 2023 •

edited by rjb1000

Loading

devbbc commented Feb 13, 2023 •

edited

Loading

devbbc commented Feb 13, 2023

Implement Server, ETag, Last-Modified and Cache-Control headers on #37

Implement Server, ETag, Last-Modified and Cache-Control headers on #37

Comments

davidjwbbc commented Feb 1, 2023 • edited by rjb1000 Loading

Specification

Server header

Entity headers

Scope of applicability

Etag header

Last-Modified header

Cache-Control header

rjb1000 commented Feb 1, 2023

rjb1000 commented Feb 1, 2023 • edited Loading

rjb1000 commented Feb 1, 2023

davidjwbbc commented Feb 1, 2023 • edited Loading

davidjwbbc commented Feb 1, 2023 • edited Loading

rjb1000 commented Feb 2, 2023 • edited Loading

rjb1000 commented Feb 2, 2023

rjb1000 commented Feb 2, 2023

rjb1000 commented Feb 2, 2023

davidjwbbc commented Feb 2, 2023 • edited Loading

rjb1000 commented Feb 2, 2023 • edited Loading

davidjwbbc commented Feb 3, 2023 • edited Loading

devbbc commented Feb 7, 2023 • edited Loading

davidjwbbc commented Feb 8, 2023 • edited by rjb1000 Loading

devbbc commented Feb 9, 2023 • edited Loading

createProvisioningSession

getProvisioningSession

createContentHostingConfiguration

retrieveContentHostingConfiguration

Error message

davidjwbbc commented Feb 9, 2023 • edited Loading

createProvisioningSession

devbbc commented Feb 13, 2023 • edited Loading

rjb1000 commented Feb 13, 2023 • edited Loading

davidjwbbc commented Feb 13, 2023 • edited by rjb1000 Loading

devbbc commented Feb 13, 2023 • edited Loading

devbbc commented Feb 13, 2023

Implement `Server`, `ETag`, `Last-Modified` and `Cache-Control` headers on #37

Implement `Server`, `ETag`, `Last-Modified` and `Cache-Control` headers on #37

davidjwbbc commented Feb 1, 2023 •

edited by rjb1000

Loading

`Server` header

`Etag` header

`Last-Modified` header

`Cache-Control` header

rjb1000 commented Feb 1, 2023 •

edited

Loading

davidjwbbc commented Feb 1, 2023 •

edited

Loading

davidjwbbc commented Feb 1, 2023 •

edited

Loading

rjb1000 commented Feb 2, 2023 •

edited

Loading

davidjwbbc commented Feb 2, 2023 •

edited

Loading

rjb1000 commented Feb 2, 2023 •

edited

Loading

davidjwbbc commented Feb 3, 2023 •

edited

Loading

devbbc commented Feb 7, 2023 •

edited

Loading

davidjwbbc commented Feb 8, 2023 •

edited by rjb1000

Loading

devbbc commented Feb 9, 2023 •

edited

Loading

`createProvisioningSession`

`getProvisioningSession`

`createContentHostingConfiguration`

`retrieveContentHostingConfiguration`

davidjwbbc commented Feb 9, 2023 •

edited

Loading

`createProvisioningSession`

devbbc commented Feb 13, 2023 •

edited

Loading

rjb1000 commented Feb 13, 2023 •

edited

Loading

davidjwbbc commented Feb 13, 2023 •

edited by rjb1000

Loading

devbbc commented Feb 13, 2023 •

edited

Loading