1

I'm trying to log the total size of a request sent out from an ASP.NET Core website hosted in Azure. The goal is to be able to attribute some sense of what the data out cost is for specific functionality within the application. (Specifically we are looking at some functionality that uses Azure Blob Storage and allows downloads of the blobs but I don't think that's relevant to the question.)

I think the solution is some simple middleware that logs out the sizes to a storage mechanism (less concerned with that part) but not sure what to put inside the middleware.

Does anyone know how you would "construct" the total size of the response being sent out of the web app.?

I would presume it will include HttpContext.Response.Body.Length but I'm pretty confident that doesn't include the headers. Also not sure if that's the compressed size of the response body or not.

Thanks

Adam Stapleton
  • 523
  • 5
  • 16
  • 1
    Possible duplicate of [Get the compressed response length in ASP.net Core](https://stackoverflow.com/questions/50924252/get-the-compressed-response-length-in-asp-net-core) – Vova Bilyachat Mar 30 '19 at 11:04
  • @VolodymyrBilyachat not a duplicate but an interesting post in a related area. – Adam Stapleton Mar 30 '19 at 15:22
  • 1
    The size of the response body is probably what you’re after. Correct, it doesn’t count in the headers, but is that really a problem in the law of larger numbers? – Anders Mar 30 '19 at 20:12
  • @Anders I think you're probably right tbh the headers are likely to be so small that it isn't worth worrying if they are included or not. Does that mean there isn't a way to get the size of the headers though or that it's just too much messing around to be worth the effort? – Adam Stapleton Mar 31 '19 at 10:12
  • @Adam I’d say it’s not worth the hassle. If you want to consider an upper bound for the response header size, see https://stackoverflow.com/a/1097727/299731 – Anders Mar 31 '19 at 16:36
  • @Adam FWIW headers are not compressed when employing HTTP compression - only the body is. – Anders Mar 31 '19 at 16:38
  • Could you confirm what is happening with your blob storage. Reason I ask is you can provide a secure link to azure blob storage and download directly from azure. This cost / number of requests can then be seen in azure. Trying to understand the link between the request size and azure blob storage as mentioned. – eVolve Mar 31 '19 at 18:55
  • @eVolve Blob storage is used to hold data from many customers so direct links can't be provided. We let customers save files within the application for a number of reasons and we manage the details of storage (we use a single storage account for everything). Not sure there is any relevance in this case just wasn't sure if I should mention it or not when I posted the question. – Adam Stapleton Apr 01 '19 at 16:30
  • @Anders Thanks I think I'll just not worry about the headers for now xD. – Adam Stapleton Apr 01 '19 at 16:32
  • you know you can secure links to download files using shared access signature https://learn.microsoft.com/en-us/azure/storage/common/storage-dotnet-shared-access-signature-part-1 So for each file, for a given user you can create a direct link for them to download a file securely and even provide a given timeframe. – eVolve Apr 01 '19 at 16:56
  • @eVolve I did know generally that SAS could be used for this. I'm not sure it would be an "easier" approach here though as we want to add logging/activity tracking of our own. I think it would just add extra work over getting the file using an internal mechanism and sending the response out via the web application. Is there any benefit you can think of to using a SAS over our current mechanism? – Adam Stapleton Apr 01 '19 at 22:56

0 Answers0