Summary
ObjectStorageClient::putObject_Helper and ObjectStorageAsyncClient::putObjectAsync_Helper initialize the request headers with Content-Type: application/json (copied from JSON-body APIs). The optional object MIME type from the $contentType parameter is added under the header name contentType, which is not the standard HTTP header for the representation of the request body.
The Oracle Object Storage API uses the standard Content-Type header for the stored object’s media type (see PutObject). As a result, clients that pass contentType (including the official stream wrapper, which infers MIME from the object key via MimeType::fromFilename) still upload objects whose stored content type is application/json, unless the service maps the non-standard contentType header (it does not in practice).
Expected behavior
- For
PUT object uploads, the primary Content-Type request header should reflect the object’s MIME type when provided.
- If
$contentType is null, a sensible default is application/octet-stream (or omit and let the service default).
Actual behavior
Content-Type remains application/json.
- The intended type is sent as header name
contentType, which does not set the object’s HTTP Content-Type metadata.
Affected code (v0.1.0)
src/Oracle/Oci/ObjectStorage/ObjectStorageClient.php — putObject_Helper
src/Oracle/Oci/ObjectStorage/ObjectStorageAsyncClient.php — putObjectAsync_Helper
Suggested fix
- Do not set
Content-Type: application/json for putObject when the body is the raw object bytes.
- Set the HTTP header
Content-Type to attemptEncodeParam($contentType) when $contentType is not null, otherwise default to application/octet-stream.
- Remove the separate
HttpUtils::addToArray($__headers, "contentType", ...) block, or map it to the standard Content-Type header as above.
The stream wrapper (StreamWrapper::stream_flush) already passes contentType in $putObjectParams; once putObject maps this to the real Content-Type header, uploads get correct metadata.
References
This report was prepared while integrating oracle/oci-php-sdk for S3 → OCI Object Storage migration; the workaround is a small patch to the generated helpers until the SDK is fixed upstream.
Summary
ObjectStorageClient::putObject_HelperandObjectStorageAsyncClient::putObjectAsync_Helperinitialize the request headers withContent-Type: application/json(copied from JSON-body APIs). The optional object MIME type from the$contentTypeparameter is added under the header namecontentType, which is not the standard HTTP header for the representation of the request body.The Oracle Object Storage API uses the standard
Content-Typeheader for the stored object’s media type (see PutObject). As a result, clients that passcontentType(including the official stream wrapper, which infers MIME from the object key viaMimeType::fromFilename) still upload objects whose stored content type isapplication/json, unless the service maps the non-standardcontentTypeheader (it does not in practice).Expected behavior
PUTobject uploads, the primaryContent-Typerequest header should reflect the object’s MIME type when provided.$contentTypeis null, a sensible default isapplication/octet-stream(or omit and let the service default).Actual behavior
Content-Typeremainsapplication/json.contentType, which does not set the object’s HTTPContent-Typemetadata.Affected code (v0.1.0)
src/Oracle/Oci/ObjectStorage/ObjectStorageClient.php—putObject_Helpersrc/Oracle/Oci/ObjectStorage/ObjectStorageAsyncClient.php—putObjectAsync_HelperSuggested fix
Content-Type: application/jsonforputObjectwhen the body is the raw object bytes.Content-TypetoattemptEncodeParam($contentType)when$contentTypeis not null, otherwise default toapplication/octet-stream.HttpUtils::addToArray($__headers, "contentType", ...)block, or map it to the standardContent-Typeheader as above.The stream wrapper (
StreamWrapper::stream_flush) already passescontentTypein$putObjectParams; onceputObjectmaps this to the realContent-Typeheader, uploads get correct metadata.References
This report was prepared while integrating
oracle/oci-php-sdkfor S3 → OCI Object Storage migration; the workaround is a small patch to the generated helpers until the SDK is fixed upstream.