I encountered an odd problem working with the Microsoft GraphAPI beta Delta Query endpoint for users.
The first 2 requests worked as expected, supplying a "nextLink" in the response.
Then, the last request (which was supposed to be the last, and according to documentation should have returned a "deltaLink" in the response) fails returning a 404 (non-JSON response).
Is this a known issue with the beta Delta Query?
The request:
https://graph.microsoft.com/beta/users/delta?$skiptoken={TOKEN_HERE}
The response:
404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.
There is a known issue in the API where the skip token size, hence the query string size, is sometimes large (> 256 characters) and service does not handle it. We are actively working on a fix. Please check your skip token size and let us know in case it does not satisfy above criteria.
This issue has been fixed. Let us know if you have any more issues or feedback on the capability.
Related
I'm trying to retrieve the educationShool list of an educationUser from Microsoft Graph per the API reference:
I am getting this error:
Error message: The request URI is not valid. Since the segment
'memberOf' refers to a collection, this must be the last segment in
the request URI or it must be followed by an function or action that
can be bound to it otherwise all intermediate segments must refer to a
single resource.
I have reproduced this issue in the Graph Explorer, if I try to send this request, I get the same error:
https://graph.microsoft.com/v1.0/education/me/schools
If I try to list the Classes (I think it should be a very similar scenario), it works ok:
https://graph.microsoft.com/v1.0/education/me/classes
Am I doing something wrong, or is this a bug in the API?
I was able to reproduce this and it looks like there may be a bug here. While that gets investigated, I can confirm that it works properly in the /beta release:
https://graph.microsoft.com/v1.0/education/me/schools
I'd suggest using /beta for this particular call if possible.
Update: This issue has been resolved and education/{users}/schools should now be working in both v1.0 and Beta versions.
We use Microsoft Graph.dll (version 1.2.1) and Microsoft.Graph.Core.dll (version 1.3.1) to extract OneDrive folder and file information (with permissions). We have been doing this successfully for over a year. When doing this we are sometimes throttled. When this happens an exception is thrown of type "Microsoft.Graph.ServiceException". This has a status code. If the status code is 429 then we know we have been throttled and we can examine the response headers in the exception to extract the required "RetryAfter" period. I believe normally the RetryPeriod is 4000ms. We have, however, just recently begun begun to see null returned in this property - which seems incorrect, we don't believe we have seen it before.
Has anybody else seen this and/or have a workaround? Has something changed....?
Many thanks ....
That does sound unexpected. I will follow up and see if something has changed. I suggest that you implement a progressive retry routine if the retryafter header is not present on a 429 or 503.
While on the topic on RetryAfter, we've implemented this in the client library (see the PR). You'll have an out of box way to do this.
I am making a call to the GRAPH API using the delta method to get Users
/beta/users/delta?$skipToken=[SKIPTOKEN]
the length of my skip token returned on the last delta request using a delta token is 17005 characters, this in turn makes the URL too long.
What methods can we use to reduce the size of the skip token?
There are over 37000 users in our AAD what we are querying and this may be the problem but not sure how the skip and delta tokens are generated.
Any help or advise would be greatly appreciated.
Is there anyway to put the skip / delta tokens in a header value to mitigate this issue?
The skipToken generated from server-side due to server-side paging, try to use $top and odata:nextLink to do paging when querying large data.
Check here for more details
This is something the team is aware of and we're investigating ways to fix it. In the meantime, you can workaround the issue by wrapping your requests in a batch request, which moves the too-long URL into the body of the POST. Not ideal, but it gets around the issue while we work on making it better :)
I have a web application which i need to be load tested using LoadRunner. When I record the website using vugen it works good and there is no any application bug. But when I tried to replay the script, script failed after login and while navigating to next page, say, Transaction. At the end of log, I receive error:
Action.c(252): Error -26612: HTTP Status-Code=500 (Internal Server Error)
for "http://rob.com/common/transaction
Please help me to resolve this error.
LoadRunner generates HTTP request just as your browser does, this error is the same error you would get if you would go to that URL using your browser. Error code 500 is a generic server error that is returned when there is no better (more specific error to return).
Most likely the login process requires some form of authentication which is protected against a replay attack by using some form of token. It is up to you to capture this token using Correlations in LoadRunner and replay it as the server expects. The Correlation Studio in VuGen should detect and identify the token for you but since authentication methods vary it is sometimes impossible to do this automatically and you will have to create manual correlation. Please consult the product documentation for more details on how to do it. If your website is publicly available online then post its URL and I will try to record the script on my machine.
Thanks,
Boris.
Most common reasons
You are not checking each request for a valid result being returned and using a 200 HTTP status as an assumed correct step without examining the content of what is being returned. As a result when data being returned is incorrect you are not branching the code to handle the exception. Go one to two steps beyond where your business process has come off the rails with an assumptive success and you will have a 500 status message for an out of context action occurring 100% of the time.
Missed dynamic element. Record three times. Compare the code. Address the changing components.
I have an iPad application which sends data to a .NET application. The iPad application was written by a bunch of monkeys who implemented all the requests as GET instead of POST.
The application is live now, and with the client's data is sending requests over 20k characters, which is giving me this response (using Safari, which has been tested to work with URLs of at least 80k characters):
Generic 414 Error
Instead of the detailed IIS response I would get if, say, the request exceeded the requestFiltering/maxURL value in the web.config, which looks like this:
IIS 414.14 Error
Since I am getting the generic error message instead of the IIS-specific message, it makes me think this is not due to something I can fix in configuration settings (I have maxURL set to 2 billion, just to be safe...)
I understand that the requests should be using POST, but I don't really have time to rewrite the iPad application at the moment, and all of my research has only turned up unhelpful responses which say "you should limit GET requests to 2K characters" "you should use a POST instead of a GET". If that is the only feedback you have, please don't bother answering. (For instance, I am aware of this question and it's answers.)
I need to know if I can throw in a quick workaround to make this function until I have time to do it the right way. And I'm also wondering if anyone knows about hard limitations URL lengths from either the iOS or IIS side, because I can't find any specifics.
Edit: My httpRuntime parameters are also set to accept far more than 20k characters.
I know this is an old one, but in case someone will face it like I did yesterday - setting web.config parameters didn't help me either. What I've found was this MS article: http://support.microsoft.com/kb/820129/en-us.
I've added two DWORD keys to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters:
MaxFieldLength = 65534
MaxRequestBytes = 100000
NOTE: you need to restart your server or at least HTTP service to make these keys work. After restart I've managed to send a request with query string length up to ~32k characters (don't know why only ~32k though, maybe character encoding?). So I guess this is the limit for URL lenght in Windows 2003 and up.
If you are seeing this in multiple clients, it's likely to be your server settings. In the .NET 4.0's httpRuntime section, the maximum values for both maxUrlLength and maxQueryStringLength are a 32 bit signed integer, or 2147483647.
<httpRuntime maxUrlLength="2147483647" maxQueryStringLength="2147483647" />