MIME Type changes for HTTP with LSL

[Oz Linden]

We are continuing to update the reliability and stability of the LSL HTTP functionality in LSL.  

The latest changes involve validating the MIME type values:

• The HTTP_MIMETYPE parameter to llHTTPRequest is checked. LSL will validate these for proper format; requests that attempt to send an improperly formatted type will send a debug channel error, not send the request, and return a null request key.

• If you use the new HTTP_ACCEPT option to llHTTPRequest (which allows you to further restrict the type your script expects), the Content-Type of the response is checked to see that it matches your restriction; if it does not, the http_response event will be a 415 error and the body will be "Unsupported or unknown Content-Type".

• Incoming HTTP requests to a script check to see if the Content-Type in the request is formatted correctly and that it is an allowed type (it always checked for allowed types). Previously, it was possible to send a type that was syntactically invalid but matched an allowed wildcard type. Incoming parameters are not validated. If an incoming request has an improperly formatted or unacceptable MIME type, LSL responds with a 415 error response and no event is generated for the script.

Valid MIME type format looks like “type/subtype; parameters” (the semicolon and parameters may be omitted). LSL does not validate the content of the optional parameter section.

Testing Your Scripts

We have made simulators implementing these checks available; regions where you can test your scripts are listed below. Please do so as soon as possible and make any required changes.

Agni regions:

• Magnum Sandbox 1

• Magnum Sandbox 2

• Magnum Sandbox 3

Aditi regions:

• Bonifacio

• Sandbox Artifex

Examples

Some examples of valid calls to llHTTPRequest include:

key my_key; 
my_key = llHTTPRequest( “http://www.mywebsite.com/”, [ HTTP_METHOD, “POST”,
                        HTTP_MIMETYPE, “text/plain;charset-utf8” ], “my body” );

key my_key; 
my_key = llHTTPRequest( “http://www.mywebsite.com/”, [ HTTP_METHOD, “POST”,
                        HTTP_MIMETYPE, “application/x-www-form-urlencoded” ],
                        “body=stuff” );


key my_key; 
my_key = llHTTPRequest( “http://www.mywebsite.com/”, [ HTTP_METHOD, “POST”,
                        HTTP_MIMETYPE, "multipart/mixed; boundary=\"---1234567890---\"" ],
                        “The body as multipart” );

 

NOTE WELL: Calls similar to the following will now be errors; they will trigger a debug error and return a Null key from llHTTPRequest. The invalid values in these examples did not trigger errors before (they probably would have caused problems on some web servers).

key my_key; 
my_key = llHTTPRequest( “http://www.mywebsite.com/”, [ HTTP_METHOD, “POST”,
                        HTTP_MIMETYPE, "text/application/xml” ], “my body” );

• The value for HTTP_MIMETYPE has too many sections (more than one '/'); it does not follow the type/subtype pattern. Values like this one used to be on the wiki page for llHTTPRequest; they were never valid but were not checked.

key my_key; 
my_key = llHTTPRequest( “http://www.mywebsite.com/”, [ HTTP_METHOD, “POST”,
                        HTTP_MIMETYPE, "text/xmll charset=utf8” ], “my body” );

• No semicolon after the mime type.

key my_key; 
my_key = llHTTPRequest( “http://www.mywebsite.com/”, [ HTTP_METHOD, “POST”,
                         HTTP_MIMETYPE, "text / xml” ], “my body” );

• The value for HTTP_MIMETYPE includes spaces in the type/subtype section.

key my_key; 
my_key = llHTTPRequest( “http://www.mywebsite.com/”, [ HTTP_METHOD, “POST”,
                         HTTP_MIMETYPE, "text/xml\n” ], “my body” );

• The value for HTTP_MIMETYPE includes a control character (A newline.)

We'll be watching this thread and will try to clarify any questions or problems you encounter. Go forth and test please!

 

[Rider Linden]

The wiki has been update with further details about HTTP_ACCEPT in llHTTPRequest.

 

[Lucia Nightfire]

Is your third bullet point actually active anywhere yet, Oz?

[Mazidox Linden]

That third bullet point is active on RC Magnum, Pie, Bluesteel, and LeTigre.

[Mazidox Linden]

On 8/17/2017 at 0:12 PM, Oz Linden said:

• If you use the new HTTP_ACCEPT option to llHTTPRequest (which allows you to further restrict the type your script expects), the Content-Type of the response is checked to see that it matches your restriction; if it does not, the http_response event will be a 415 error and the body will be "Unsupported or unknown Content-Type".

• Incoming HTTP requests to a script check to see if the Content-Type in the request is formatted correctly and that it is an allowed type (it always checked for allowed types). Previously, it was possible to send a type that was syntactically invalid but matched an allowed wildcard type. Incoming parameters are not validated. If an incoming request has an improperly formatted or unacceptable MIME type, LSL responds with a 415 error response
   

The above changes are now grid-wide on the Second Life Server channel.

 

On 8/17/2017 at 0:12 PM, Oz Linden said:

• The HTTP_MIMETYPE parameter to llHTTPRequest is checked. LSL will validate these for proper format; requests that attempt to send an improperly formatted type will send a debug channel error, not send the request, and return a null request key.

The above change is will be on RCs Magnum, BlueSteel, and LeTigre tomorrow morning, Pacific Time.

Should you find any unexpected behavior with these new HTTP fixes and features, please file a bug report at jira.secondlife.com.

Edited August 22, 2017 by Mazidox Linden
Whoops, got ahead of myself. We're not putting new code on RCs until 8/23.

[Mazidox Linden]

 

On 8/17/2017 at 0:12 PM, Oz Linden said:

We are continuing to update the reliability and stability of the LSL HTTP functionality in LSL.  

The latest changes involve validating the MIME type values:

• The HTTP_MIMETYPE parameter to llHTTPRequest is checked. LSL will validate these for proper format; requests that attempt to send an improperly formatted type will send a debug channel error, not send the request, and return a null request key.

• If you use the new HTTP_ACCEPT option to llHTTPRequest (which allows you to further restrict the type your script expects), the Content-Type of the response is checked to see that it matches your restriction; if it does not, the http_response event will be a 415 error and the body will be "Unsupported or unknown Content-Type".

• Incoming HTTP requests to a script check to see if the Content-Type in the request is formatted correctly and that it is an allowed type (it always checked for allowed types). Previously, it was possible to send a type that was syntactically invalid but matched an allowed wildcard type. Incoming parameters are not validated. If an incoming request has an improperly formatted or unacceptable MIME type, LSL responds with a 415 error response and no event is generated for the script.

Valid MIME type format looks like “type/subtype; parameters” (the semicolon and parameters may be omitted). LSL does not validate the content of the optional parameter section.

The above changes are now grid-wide on Second Life Server channel.

Please continue to file a bug report at jira.secondlife.com if you find any unexpected behavior with these new HTTP fixes and features.