DevTest API returns resource group name in lower-case

[tombuildsstuff]

👋

We've been working with version 2016-05-15 of the DevTest API's (via v20.1.0 of the Azure SDK for Go) - and have noticed a bug where the Resource Group name that's returned from Azure is always lower-cased for the ID, regardless of the input case. For example if I create a DevTest Lab in the resource group Group1 the ID for create will be:

/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/group1/providers/Microsoft.DevTestLab/labs/lab1/virtualnetworks/network1

when actually this should be:

/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/Group1/providers/Microsoft.DevTestLab/labs/lab1/virtualnetworks/network1

Would it be possible to update this API to return the Resource Group name in the correct case, rather than lower-casing it?

Thanks!

[tombuildsstuff]

ping @sarangan12 :)

[tombuildsstuff]

@jhendrixMSFT since this has been open for a few months and we've not heard back would it be possible to escalate this to the Service Team?

[jhendrixMSFT]

@tombuildsstuff I'll forward this to the RP, sorry for the delay.

[tombuildsstuff]

@jhendrixMSFT no worries :) did you hear back from the RP team in the end?

[jhendrixMSFT]

@tombuildsstuff the email thread died, I've asked for an update and for the service team to comment on this issue.

[tombuildsstuff]

No worries - thanks @jhendrixMSFT :)

[salameer]

@jviau can you kindly look into this?

[jhendrixMSFT]

The service team has opened a bug in their internal database to track this issue and I've asked them to update this issue as appropriate.

[joshgav]

Hi @tombuildsstuff it will be difficult to change the API. Can you explain why case matters to you? Thanks!

[tombuildsstuff]

hey @joshgav

We've found historically that API's require that the casing of fields they consume is correct, particularly when it comes to Resource ID's - since otherwise they can provision successfully but be unusable (for example, the Databricks API issue where the API provisions successfully but you're unable to login because the case passed to the API was incorrect). Specifically with Resource ID's this leads to subtle bugs which leads us to treat Resource ID's as case sensitive throughout our codebase (even though parts of them are theoretically case insensitive).

In addition, since Resources are returned using the Schema from the last time they were modified - we're forced to be very careful when parsing data out of the API, since this could not match the schema used in the SDK or the fields could be missing from the response altogether (which leads to crashes). Over the next few weeks we'll be rolling out a change to make Enum's case sensitive too (so that this behaviour is consistent across the Provider) - which should give us more of an idea which of the API's are broken (insofar as they return values in the incorrect case).

Hope that helps :)

Thanks!

[joshgav]

Thanks @tombuildsstuff and thanks for the Databricks example where resource IDs are treated case sensitively. Could you please share other APIs where you've found this problem?

Per Resource Manager's specs APIs should treat resource IDs case-insensitively, and other services like DevTestLabs will point to that spec and ask Databricks to fix its behavior rather than themselves treat resource IDs case-sensitively. This is because other parts of their systems have taken a dependency on case-insensitivity.

Would it help to pursue APIs like Databricks which treat IDs case-sensitively and ask them to meet the spec?

ref: Azure/azure-sdk-for-go#1943
ref: hashicorp/terraform-provider-azurerm#2214

[sindstar]

@tombuildsstuff ,Would a script help? Something that takes the returned DTL ID and replaces the RG with the correct casing? This should be simple enough to do if a GET on the RG has a field with the correct casing (which I believe exists).

[tombuildsstuff]

@sindstar whilst I appreciate the thought (and that's technically possible), unfortunately that's not practical as a workaround since we'd need to apply that to each response we get from both user input and the SDK (to ensure that's consistent across all resources) - since we'd need this value to be correct before passing it to another API.

@joshgav

Thanks @tombuildsstuff and thanks for the Databricks example where resource IDs are treated case sensitively. Could you please share other APIs where you've found this problem?

I don't have a particular example to hand - but we'll try and file issues when we see them going forwards.

Per Resource Manager's specs APIs should treat resource IDs case-insensitively, and other services like DevTestLabs will point to that spec and ask Databricks to fix its behavior rather than themselves treat resource IDs case-sensitively. This is because other parts of their systems have taken a dependency on case-insensitivity.

Whilst that's valid in the context of those specs - I'd argue that most consumers of the API would expect this to follow RFC7230 (snippet below) which states that URI Components should be treated as case-sensitive?

The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.

[katbyte]

👋 Hello all,

just wondering if there has been any progress on this as I have discovered the problem in a few other APIs (issues to follow as i fix the provider) @jhendrixMSFT

[ericwolz]

@sindstar whilst I appreciate the thought (and that's technically possible), unfortunately that's not practical as a workaround since we'd need to apply that to each response we get from both user input and the SDK (to ensure that's consistent across all resources) - since we'd need this value to be correct before passing it to another API.
@joshgav

Thanks @tombuildsstuff and thanks for the Databricks example where resource IDs are treated case sensitively. Could you please share other APIs where you've found this problem?

I don't have a particular example to hand - but we'll try and file issues when we see them going forwards.

Per Resource Manager's specs APIs should treat resource IDs case-insensitively, and other services like DevTestLabs will point to that spec and ask Databricks to fix its behavior rather than themselves treat resource IDs case-sensitively. This is because other parts of their systems have taken a dependency on case-insensitivity.

Whilst that's valid in the context of those specs - I'd argue that most consumers of the API would expect this to follow RFC7230 (snippet below) which states that URI Components should be treated as case-sensitive?

The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.

RFC7230 spec defines the client access to resources on the server. There is no definition that the server respects the symmetry of the URI resource. It is expected that clients maintain the URI when accessing the resource on the server. The assumption here is that the URI components are hieratical, but there is no definition on that, other than users perception, of the URI contents. Servers are free to generate any URI for a given resource. It is expected that the client uses the URI in a case sensitive manor when requesting the resource.

[tombuildsstuff]

@ericwol-msft 👋 is there a timeline for when this bug in the API will be fixed?