I am trying get past some unit test after upgrading from Microsoft.Azure.Blob to Azure.Storage.Blobs. My connection to BlobServiceClient is
// create service client:
var blobServiceClient = BlobServiceClient("UseDevelopmentStorage=true")
//create container
BlobContainerClient container = client.GetBlobContainerClient(containerName);
//my code blows up on 'container.exists()'...but I don't get read access error.
//RequestFailedException : "The value for one of the HTTP headers is not in the correct format."
if(!container.Exists())
container = client.CreateBlobContainer(containerName).Value;
BlobClient blobClient = container.GetBlobClient($"{blobName}.json");
await blobClient.UploadAsync(BinaryData.FromString(jsonContent), options);
Wondering if anyone knows if there is some limitation on using azurite and the latest libs?
checking my container it 'looks' to me like it is ok? I have tried using the provided connection strings from within Microsoft Azure Storage explorer as well and had the same issues. I can't understand what it means by my headers are incorrect. The other answers are related to functions and also gt 4 years old. I feel like this issue is something to do with my unit test setup.
The actual error message:
The value for one of the HTTP headers is not in the correct format.
RequestId:5b9f9072-606b-4dfa-b174-19ef2fa2c20d
Time:2023-01-27T00:02:23.357Z
Status: 400 (The value for one of the HTTP headers is not in the correct format.)
ErrorCode: InvalidHeaderValue
Additional Information:
HeaderName: x-ms-version
HeaderValue: 2021-10-04
Content:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Error>
<Code>InvalidHeaderValue</Code>
<Message>The value for one of the HTTP headers is not in the correct format.
RequestId:5b9f9072-606b-4dfa-b174-19ef2fa2c20d
Time:2023-01-27T00:02:23.357Z</Message>
<HeaderName>x-ms-version</HeaderName>
<HeaderValue>2021-10-04</HeaderValue>
</Error>
Headers:
Server: Azurite-Blob/3.17.1
x-ms-error-code: InvalidHeaderValue
x-ms-request-id: 5b9f9072-606b-4dfa-b174-19ef2fa2c20d
Date: Fri, 27 Jan 2023 00:02:23 GMT
Connection: keep-alive
Keep-Alive: REDACTED
Transfer-Encoding: chunked
Content-Type: application/xml
The error is happening because the Storage REST API version supported by your installation of Azurite (v3.17.1) is not the latest REST API version which is supported by the version of SDK (12.14.1) you are using.
To fix this issue, there are a few options:
Update your installation of Azurite to the latest version. Looking at Azurite releases, REST API version 2021-10-04 support is included in version 3.19.0.
Use cloud storage for development if possible. That way you will not run into these versioning issues.
Though not recommended but if you want to keep on using version 3.17.1 of Azurite, you would need to downgrade the SDK to a version that has support for the same REST API version.
Related
Can I remove default HTTP headers from a SOAPReply node?
I tried to Overwrite it in ESQL and tried removing it using HTTPHeader node, I succeded in creating new HTTP Headers but failed to remove the default ones (for example "Server: IBM App Connect Enterprise").
The weird thing is that the same code works with HTTPReply node but not with SOAPReply node. Any suggestions?
My ESQL code:
SET OutputRoot.HTTPReplyHeader."Server" = 'MyDummyValue';
Output of HTTPReply node:
HTTP/1.1 200 OK
Content-Type: text/xml
Server: MyDummyValue
Output of SOAPReply node:
HTTP/1.1 200 OK
Content-Type: text/xml
Server: IBM App Connect Enterprise
I tried to override it in the Integration Server YAML file (server.conf.yaml) and it worked as expected for both HTTP and SOAP flows.
The value you need to override is:
/ResourceManagers/HTTP[S]Connector/ServerName
I checked this page: https://www.ibm.com/docs/en/app-connect/11.0.0?topic=node-local-environment-overrides-soapreply and I cannot see any local environment override that would suppress the default headers in a SOAPReply node.
The Server header is in an internal list of headers that we don't allow you to set. I suspect it is to ensure that receiving clients know how to process the SOAP messages from ACE, we might have had a situation where it was overwritten and a client application failed, and it was added to the list.
Is there a particular reason why you need to modify the Server header?
I currently have some code that uses http patch to send Microsoft CRM data via the 2016 web api. When my payload includes a text or int datatype it works just fine, but when the payload includes a lookup record I can't get any response beyond 400 bad request.
Below are a few of the instances of payload that I've tried (with sensitive data altered)
payload = {"new_lastweblocation": "Midlothian" }
payload = {"new_location_transaction_LastWebLocationid#odata.bind" : "https://crmnaorgXXXX.crm.dynamics.com/api/data/v8.0/new_locations(1234578-a588-e511-8105-c4346bace18c)"}
payload = {"new_lastweblocation#odata.bind" : "https://crmnaorgXXXX.crm.dynamics.com/api/data/v8.0/new_locations(1234578-a588-e511-8105-c4346bace18c)"}
Essentially I've tried passing plaintext, a guid to the record, a guid to the relationship, a guid linked via odata.bind ... etc.
Clearly my shotgun approach along with the 400 error means that I fundamentally misunderstand how entities are handled in the 2016 web api. Let me know if you have any suggestions.
The approach listed on MSDN for associating entities on create also works when updating. I tested the following query in a 2016 demo environment without issues (where the guids have been replaced with existing account and contact guids, respectively):
PATCH [Organization URI]/api/data/v8.0/accounts/(00000000-0000-0000-0000-000000000001) HTTP/1.1
Content-Type: application/json; charset=utf-8
OData-MaxVersion: 4.0
OData-Version: 4.0
Accept: application/json
{
"name":"Sample Account",
"primarycontactid#odata.bind":"/contacts(00000000-0000-0000-0000-000000000001)"
}
Could you start by verifying that this out-of-the-box use case works before debugging your specific issue with the lookup to a custom entity?
I ended up using this request. The main issue that I was having is that I didn't know what the single-valued navigation property was. To find that I ended up using this request. I altered the select in the url to be select="*"
Original URL
GET [Organization URI]/api/data/v8.1/incidents(39dd0b31-ed8b-e511-80d2-00155d2a68d4)?$select=title,customerid_value&$expand=customerid_contact($select=fullname)
My URL
GET [Organization URI]/api/data/v8.1/incidents(39dd0b31-ed8b-e511-80d2-00155d2a68d4)?$select=*
When using the GET request to try and find the single-valued navigation property make sure to add 'Prefer':'odata.include-annotations"*". I couldn't get the preference header to pass until I put it before my authorization header.
Finally once I got a response from the get request I looked for the variable I was looking for with #Microsoft.Dynamics.CRM.associatednavigationproperty at the end of it and the used the value associated with that. In my case, the field name was new_lastweblocation but the single-value navigation property was new_LastWebLocation
I'm working on an app using Visual Studio 2015 Cordova tools on Windows 8.1. Target is also Windows 8.1.
The app is caching HTTP GET request. So the second GET request to the same resource returns a cached response. I have tested after disabling the network adapter and I still get a response with the cached results.
I am using jsforce libray to connect to salesforce.com. I know I can add a timestamp on the url but I would like to find fix not a work around.
Any ideas?
[UPDATE]
Issue is not related to jsforce as it works well on Android. The error is specific to Windows 8.1 and cordova.
As suggested in the question, timestamping the url helps: I used:
var url = "https://api.myurl.com/" + param1 + "?" + new Date().getTime()
I wrote a simple library to add caching to REST requests for Cordova: https://github.com/glauber-md/mobile-simple-web-call#using-this-library .
The library will use a local database (sqlite) to fetch server data and cache it locally where applicable (e.g. HTTP GET requests with cache-related headers).
Once it receives a 304 Response, it will use the cached data.
To send a GET request, you'd use:
wscall.get(
'http://myserver.org/users/1234',
// (Optional) query strings
null,
function(responseData) {
// Do something when the response is successful
},
function(error) {
// Do something when an error happens
}
);
Then the data would come from remote server or local cache depending of the HTTP server response.
Maybe it will help you.
I'm running a Piranha CMS based page, using it as a content source in passive mode.
While working on optimizing pagespeed i saw that all image requests handled by piranha return the following response headers:
GET /media/4b3b3fa3-ff7b-4af7-81f2-168474edd23f/50/20
Cache-Control:no-cache
Content-Length:52826
Content-Type:image/jpeg
Date:Mon, 17 Nov 2014 11:53:28 GMT
Expires:-1
Pragma:no-cache
X-UA-Compatible:IE=Edge,chrome=1
Naturally, i want these images to be cached where possible.
I looked around the code on github and saw that this information appears to be set in /Piranha/Web/ClientCache.cs.
Is there a way to influence the caching headers set by piranha?
The configuration section isn't all that clear in the current version but the caching is controlled by two parameters that you can set in the manager interface from System > Parameters. Here you have the two parameters CACHE_PUBLIC_EXPIRES and CACHE_PUBLIC_MAXAGE which specifies the time, in minutes, of the client browser cache.
These are set to 0 by default since you don't want cache enabled during development which disables the cache and renders the no-cache headers. When you activate the cache E-tag, Last modified & Expires headers will be generated for your media files.
Best regards
Håkan
I am using asp.net mvc3, download file in the same browser (Chrome 22). Here is the controller code:
[HttpPost]
public ActionResult Uploadfile(HttpPostedFileBase file)//HttpPostedFileBase file, string excelSumInfoId)
{
...
return File(
result.Output,
"application/vnd.ms-excel",
String.Format("{0}_{1:yyyy.MM.dd-HH.mm.ss}.xls", "Суммирование", DateTime.Now));
}
On my dev machine I download a programmatically created file with the correct name "Суммирование_2012.10.18-13.36.06.xls".
Response:
Content-Disposition:attachment; filename*=UTF-8''%D0%A1%D1%83%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_2012.10.18-13.36.06.xls
Content-Length:203776
Content-Type:application/vnd.ms-excel
Date:Thu, 18 Oct 2012 09:36:06 GMT
Server:ASP.NET Development Server/10.0.0.0
X-AspNet-Version:4.0.30319
X-AspNetMvc-Version:3.0
And from production server I download a file with the name of the controller's action + correct extension "Uploadfile.xls", which is wrong.
Response:
Content-Disposition:attachment; filename="=?utf-8?B?0KHRg9C80LzQuNGA0L7QstCw0L3QuNC1XzIwMTIuMTAuMTgtMTMuMzYu?=%0d%0a =?utf-8?B?NTUueGxz?="
Content-Length:203776
Content-Type:application/vnd.ms-excel
Date:Thu, 18 Oct 2012 09:36:55 GMT
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-AspNetMvc-Version:3.0
X-Powered-By:ASP.NET
Web.config files are the same on both machines.
Why does filename gets encoded differently for the same browser? Are there any kinds of default settings in web.config that are different on machines that I am missing?
The dev server is running .NET 4, and the production server is running .NET 4.5. The MVC framework contains a heuristic for determining whether it needs to use RFC 6266 for the Content-Disposition header, and while this heuristic works correctly on .NET 4 it does not work correctly on .NET 4.5. The end result is that the Content-Disposition header gets mangled, as you're witnessing in this instance.
Your easiest course of action would probably be to upgrade the application to MVC 4. That version of the framework contains a different heuristic that is more robust and should work correctly on both .NET 4 and .NET 4.5.
Most likely reason seems to be that the server indeed sees different User-Agent header fields.
That being said, the 2nd response isn't correct for any browser, and you should report that problem to Microsoft.