Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-40656] Cookie support for HTTP requests and responses #12301

Closed
sl-service-account opened this issue Oct 7, 2016 · 1 comment
Closed

Comments

@sl-service-account
Copy link

How would you like the feature to work?

llGetHTTPCookiesCount()

integer llGetHTTPCookiesCount(key request_id);

returns: the number of cookies received by a http_request() or http_response() event with key of request_id.

llGetHTTPCookie()

list llGetHTTPCookie(key request_id, integer num);

Retrieves the data for a cookie received by a http_request() (Cookie headers) or http_response() (Set-Cookie headers) event.

  • request_id - the key of the request/response to retrieve cookie data for.
  • num - the index of the cookie to retrieve.

returns: an empty list for an invalid cookie index, otherwise returns a list containing the cookie name and value. When called within a http_response() event the list will also include the integer max age (after which the cookie expires).

llSetHTTPCookie()

llSetCookie(key request_id, string name, string value, integer max_age);

Sets a cookie to be sent by an llHTTPResponse().

  • request_id: the key of the http_request() for which to send cookies in response to.

  • name: the name of the cookie to set.

  • value: the value to set for the cookie.

  • max_age: the time (in seconds) after which the cookie should expire.

    HTTP_COOKIE

    To complete the set, also proposed is a new HTTP_COOKIE constant for use in the options list for an llHTTPRequest(), accepting two strings providing the name and value of a cookie to set.

    Cookies are subject to the same restrictions as HTTP_CUSTOM_HEADER, this is merely a convenient alternative to building a cookie header manually.

    HTTP_REQUEST_COOKIES

    A final optional addition is another HTTP_REQUEST_COOKIES constant for use in the options list for llHTTPRequest(). The purpose of this is to indicate whether cookies should be retrieved for use in the above functions inside the http_response() event, otherwise cookies are discarded.

    This constant would not take a value, being present in the list should be sufficient to enable cookie retrieval.

    Why is this feature important to you? How would it benefit the community?

    The inability to support cookies in HTTP requests/responses means extra work is required in order to handle stateful messaging, usually requiring total control of both the sender and receiver since session data must be passed in the request/response body instead.

    Since cookies are just a special case of header, most of the handling should already exist, all that is required is to expose the data to the scripts themselves.

Original Jira Fields
Field Value
Issue BUG-40656
Summary Cookie support for HTTP requests and responses
Type New Feature Request
Priority Unset
Status Closed
Resolution Unactionable
Reporter Haravikk Mistral (haravikk.mistral)
Created at 2016-10-07T10:30:33Z
Updated at 2016-10-12T18:42:47Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2016-10-12T13:42:47.338-0500',
  'How would you like the feature to work?': 'h3. llGetHTTPCookiesCount()\r\n{code}integer llGetHTTPCookiesCount(key request_id);{code}\r\n*returns*: the number of cookies received by a [{{http_request()}}|https://wiki.secondlife.com/wiki/http_request] or [{{http_response()}}|https://wiki.secondlife.com/wiki/http_response] event with key of *request_id*.\r\n\r\nh3. llGetHTTPCookie()\r\n{code}list llGetHTTPCookie(key request_id, integer num);{code}\r\nRetrieves the data for a cookie received by a {{http_request()}} or {{http_response()}} event.\r\n\r\n* *request_id* - the key of the request/response to retrieve cookie data for.\r\n* *num* - the index of the cookie to retrieve.\r\n\r\n*returns*: an empty list for an invalid cookie index, otherwise returns a list containing the cookie name and value. When called within a {{http_request()}} event the list will also include the integer max age (after which the cookie expires).\r\n\r\nh3. llSetHTTPCookie()\r\n{code}llSetCookie(key request_id, string name, string value, integer max_age);{code}\r\nSets a cookie to be sent by an [{{llHTTPResponse()}}|https://wiki.secondlife.com/wiki/LlHTTPResponse].\r\n\r\n* *request_id*: the key of the {{http_request()}} for which to send cookies in response to.\r\n* *name*: the name of the cookie to set.\r\n* *value*: the value to set for the cookie.\r\n* *max_age*: the time (in seconds) after which the cookie should expire.\r\n\r\nh3. HTTP_COOKIE\r\nTo complete the set, also proposed is a new {{HTTP_COOKIE}} constant for use in the {{options}} list for an [{{llHTTPRequest()}}|https://wiki.secondlife.com/wiki/LlHTTPRequest], accepting two strings providing the name and value of a cookie to set.\r\n\r\nCookies are subject to the same restrictions as {{HTTP_CUSTOM_HEADER}}, this is merely a convenient alternative to building a cookie header manually.\r\n\r\nh3. HTTP_REQUEST_COOKIES\r\nA final optional addition is another {{HTTP_REQUEST_COOKIES}} constant for use in the {{options}} list for {{llHTTPRequest()}}. The purpose of this is to indicate whether cookies should be retrieved for use in the above functions inside the {{http_response()}} event, otherwise cookies are discarded.\r\n\r\nThis constant would not take a value, being present in the list should be sufficient to enable cookie retrieval.',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'The inability to support cookies in HTTP requests/responses means extra work is required in order to handle stateful messaging, usually requiring total control of both the sender and receiver since session data must be passed in the request/response body instead.\r\n\r\nSince cookies are just a special case of header, most of the handling should already exist, all that is required is to expose the data to the scripts themselves.',
}
@sl-service-account
Copy link
Author

Oz Linden commented at 2016-10-12T18:42:47Z

See BUG-40653

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant