PUT Buffer
- Updated2023-02-17
- 5 minute(s) read
PUT Buffer
Creates or updates data within the buffer input and sends the data to the URL you specify.
Unlike a POST request, PUT requests require all available property and attribute values to be present because the PUT request updates all data within the resource. Adding all available property and attribute values will guarantee that the operation can be performed multiple times without changing the result beyond the initial application.

Inputs/Outputs

output file
File to save body data returned by the server. If you do not specify an output file, the node does not save the body data to a file.

client handle
Unique value that identifies the web request. You can use the same client handle to wire together multiple HTTP nodes to preserve authentication credentials, HTTP headers, and cookies. Client handles are not required when making independent web requests without persistent data such as headers or credentials.
Default value: 0

url
URL of the server, web page, or web service where this node will send the web request.
Relative URL behavior
If you do not specify a URL scheme on a Web Server target, each URL you enter is relative to the location the WebVI is hosted. The WebVI sends HTTP requests to the server at the relative URL. For example, if you host the WebVI on http://website.com/MyApp/, specifying the relative URL subdirectory/myfile.txt sends an HTTP request to http://website.com/MyApp/subdirectory/myfile.txt.
If you do not specify a URL scheme on a non-Web Server target, the node prefixes http:// to the URL and treats it as an absolute URL.

buffer
String of data to send to the server.

error in
Error conditions that occur before this node runs.
The node responds to this input according to standard error behavior.
Default value: No error

timeout
Amount of time in milliseconds you must wait to obtain a response from the server before the web request times out. A value of -1 defers timeout monitoring to the operating system.
Default value: 10000 ms

status code
Status code information returned by the server.

client handle out
Unique value that returns data back to the node. You can use the same client handle to wire together multiple HTTP nodes to preserve authentication credentials, HTTP headers, and cookies. Client handles are not required when making independent web requests without persistent data such as headers or credentials.

headers
Header fields returned by the server. Refer to the World Wide Web Consortium website at www.w3.org for more information about header field definitions including available headers, descriptions, and syntax.

body
Body data that is returned by the server.

error out
Error information.
The node produces this output according to standard error behavior.
CORS Restrictions on HTTP Requests
Requests from HTTP clients are subject to CORS restrictions when the WebVI communicates with a web service on a different origin. The web service responding to the HTTP request must return a valid CORS configuration for the HTTP request to complete successfully.
On non-Web Server targets, HTTP requests are not subject to CORS restrictions. The VI can make HTTP requests regardless of the CORS configuration of the server.
Cached Response Behavior for Repeat Requests
HTTP nodes on a Web Server target may create caches of responses to HTTP requests. If a duplicate request occurs, the HTTP nodes can avoid querying the network by returning a previous response from the cache. The specific browser environment and server configuration determine the behavior of the cache.
On non-Web Server targets, every HTTP request creates a unique network request.
Forbidden Headers on a Web Server
A WebVI cannot transmit or receive specific forbidden headers in HTTP requests. For header transmissions, the request to the server does not include forbidden headers. When the HTTP nodes receive a forbidden header from a server, they exclude the header from the headers output. Additionally, the CORS configuration of a server may exclude some headers in server requests or from server responses.
On non-Web Server targets, you do not need to account for forbidden headers in HTTP requests.
Default Content-Type for HTTP Request
If you do not specify a Content-Type header for an HTTP request, this node adds the application/x-www-url-formencoded Content-Type header to the request by default. However, on non-Web Server targets this node does not add a Content-Type header to requests.
Related Information
- POST
Sends data to the URL you specify.
- POST Buffer
Sends data within the buffer input to the URL you specify.