I try to get the last builds of some build definitions in my TFS (Team Foundation Server) with:
project/_apis/build/builds?definitions=1000,1001&queryOrder=queueTimeDescending&minTime=2020-05-03T00:00:00
This works until the string for "definitions" reach a limit of 440 definitions or 1984 characters.
Then I get a 404-Error on the request.
Is there such an (undocumented) limit in the number of definitions or length for the parameter string?
It is not clearly state how long url can be, but it looks that you reached the limit. However according to this What is a safe maximum length a segment in a URL path should be? it is good practice to do not extend 2000 characters. I see that you count almost 2K, so this maybe is your case.
You can also check this topic on developer community. There were discussion about this with conclusion:
At present, you can only reduce the length of URL.
Related
Is there an EDI x12 segment that has no character limit? We often use the MSG segment for open text fields but this is capped at 256 characters, so we’re looking for an alternative that can handle 500+ characters.
The short answer
The MTX Text segment allows you to send messages of up to 4096 characters long, which is the longest available in X12. You can’t just swap out an MSG segment for an MTX segment, though. You can only use MTX if it’s included in the transaction set, and that depends on which X12 'release' (version) you're using.
For the 005010 release (one of the more popular ones), here are the transaction sets that MTX appears in:
105 Business Entity Filings
113 Election Campaign and Lobbyist Reporting
150 Tax Rate Notification
155 Business Credit Report
179 Environmental Compliance Reporting
194 Grant or Assistance Application
251 Pricing Support
274 Healthcare Provider Information
284 Commercial Vehicle Safety Reports
500 Medical Event Reporting
620 Excavation Communication
625 Well Information
650 Maintenance Service Order
805 Contract Pricing Proposal
806 Project Schedule Reporting
814 General Request, Response or Confirmation
832 Price/Sales Catalog
836 Procurement Notices
840 Request for Quotation
843 Response to Request for Quotation
850 Purchase Order
855 Purchase Order Acknowledgment
860 Purchase Order Change Request - Buyer Initiated
865 Purchase Order Change Acknowledgment/Request - Seller Initiated
Some additional clarification
Technically, character limits don't apply to X12 segments – what you're referring to is an X12 element. A segment is just a container for elements, and the element you're referring to is the element referenced in MSG01 (the first element of the MSG segment).
Each X12 element references an ID number. For each element, the ID number points to a dictionary that specifies the name, description, type, minimum length, and maximum length. In the case of MSG01, it points to data element [933][1].
Data element 933 – the one you're currently using – actually has a character limit of 264 characters (more than 256 characters, but not by much). Note: the link above is to the 005010 X12 release, but I checked backed to 003010 and up to 008030 and it seems to be 264 characters all the way through.
Now, back to your original question: is there a data element that allows for a larger character payload?
The answer is that there are 8 data elements that accept a payload larger than 264 characters.
Two of them are binary data types, which we can likely eliminate off the bat:
785. Binary Data. A string of octets which can assume any binary pattern from hexadecimal 00 to FF. Note: The maximum length is dependent upon the maximum data value that can be entered in DE 784, which value is 999,999,999,999,999. Max characters: 999999999999999.
1700. Transformed Data. Binary or filtered data having one or more security policy options applied; transformed data may represent compressed, encrypted, or compressed and encrypted plaintext. Max characters: 10000000000000000.
The rest are strings, which is promising:
364. Communication Number. Complete communications number including country or area code when applicable. Max characters: 2048.
1565. Look-up Value. Value used to identify a certificate containing a public key. Max characters: 4096.
1566. Keying Material. Additional material required for decrypting the one-time key. Max characters: 512.
1567. One-time Encryption Key. Hexadecimally filtered encrypted one-time key. Max characters: 512.
1573. Encoded Security Value. Encoded representation of the Security Value specified by the Security Value Qualifier. Max characters: 1.00E+16.
And, last but not least:
1551. Textual Data. To transmit large volumes of message text. Max characters: 4096.
Looks like a winner!
Note that element 1551 appears in only one segment: MTX, which was introduced in the 003060 X12 release. And in the initial 003060 release, it was only included in one X12 Transaction Set: 194 Grant or Assistance Application (which makes sense – a longer field was needed for grant applications).
It seems that as new releases were developed, the MTX segment made its way into more and more transaction sets – likely for exactly the reason you're asking. In 003070, it was included in 5 transaction sets; in 004010, 15; in 005010, 24, and so on.
The MTX segment uses element 1551 in both MTX02 and MTX03, so you can get double the length by using both of them. Note that there's a 'relational condition': If MTX-03 is present, then MTX-02 is required (in other words, you can't use MTX03 if you don't use MTX02 first).
And depending on the transaction set, the MTX segment may be able to be repeated as well.
Long story short: if the MTX segment is in the transaction set / release you're using, you're likely in luck.
Hope this helps.
Use multiple MSGs and trim the data at each to the maximum allowed. You usually have free text segments set with repetitions > 1, so you should be okay. That's how everybody does it.
What is MS Graph "subscription id" property max length?
In examples length of id is 36 characters (e.g. "7f105c7d-2dc5-4530-97cd-4e7ae6534c07").
It will be always like this? I can't find info in documentation.
The documentation doesn't explicitly states it is an UUID... though it certainly looks line one, probably will be one, and will most likely always be one. However, imho, unless you really have problems in terms of storage, it is best to reserve a reasonable size and assume this ID is a "opaque string" that you just store, and assume is unique (so you can make some key of it, or build an index on it, if you would be referring to a database as the storage). If there are other reasons why you need to know the side, please clarify...
GetWorkItemsAsync fails when it retrieves 1800 workitems. Example:
int[] ids = (from WorkItem info in wlinks select info.Id).ToArray();
WorkItemTrackingHttpClient tfvcClient = _tfs.GetClient<WorkItemTrackingHttpClient>();
List<Microsoft.TeamFoundation.WorkItemTracking.WebApi.Models.WorkItem> dworkitems = tfvcClient.GetWorkItemsAsync(ids).Result;
If I pass array of Ids with 90 elements it works fine.
Is there any limit that it can get only n number of elements, how can we overcome this problem?
Yes, there is a limitation of the URL length, it will get this exception once the URL length has been exceeded.
So, as a workaround you can limit your calls to a allowed range at a time (e.g. 200 ids at a time). Then call several times for the query.
Unfortunately you’ve hit a limitation of the URL length. Once the URL
length has been exceeded, the server just gets the truncated version,
so odds are high that the truncated work item id is not valid.
I recommend limiting your calls to 200 ids at a time.
Source here :
https://github.com/Microsoft/vsts-dotnet-samples/issues/49
Reference this thread for the limitation of the URL length: What is the maximum length of a URL in different browsers?
This similar thread for your reference: Is there any restriction for number of characters in TFS REST API?
The implementation guides (and most web resources I can find) describe the GS06 and ST02 Control Numbers as being unique only within the Interchange they are contained in. So when we build our GS and ST segments we just start the control numbers at 1 and increment as we add more Functional Groups and/or Transaction Sets. The ISA13 control numbers we generate are always unique.
The dilemma is when we receive a 999 acknowledgment; it does not include any reference to the ISA control number that it's responding to. So we have no way to find the correct originating Functional Group in our records.
This seems like a problem that anyone receiving functional acknowledgements would face, but clearly lots of systems and companies handle it, so what is the typical practice to reconcile 997s or 999s? I think we must be missing something in our reading of the guides.
GS06 and ST02 only have to be unique within the interchange, but if you use an ID that's truly unique for each one (not just within the message), then you can skip right to the proper transaction set or functional group, not just the right message.
I typically have GS start at 1 and increment the same way that you do, but the ST02 I keep unique (to the extent allowed by the 9 character limit).
GS06 is supposed to be globally unique, not only within the interchange. This is from X12-6
In order to provide sufficient discrimination for the acknowledgment
process to operate reliably and to ensure that audit trails are
unambiguous, the combination of Functional ID Code (GS01), Application
Sender's ID (GS02), Application Receiver's ID (GS03), and Functional
Group Control Numbers (GS06, GE02) shall by themselves be unique
within a reasonably extended time frame whose boundaries shall be
defined by trading partner agreement. Because at some point it may be
necessary to reuse a sequence of control numbers, the Functional Group
Date and Time may serve as an additional discriminant only to
differentiate functional group identity over the longest possible time
frame.
What is the maximum URL length you can pass to the Wininet function, HttpOpenRequest?
There are some max length consts in WinInet.h:
...
//
// maximum field lengths (arbitrary)
//
#define INTERNET_MAX_HOST_NAME_LENGTH 256
#define INTERNET_MAX_USER_NAME_LENGTH 128
#define INTERNET_MAX_PASSWORD_LENGTH 128
#define INTERNET_MAX_PORT_NUMBER_LENGTH 5 // INTERNET_PORT is unsigned short
#define INTERNET_MAX_PORT_NUMBER_VALUE 65535 // maximum unsigned short value
#define INTERNET_MAX_PATH_LENGTH 2048
#define INTERNET_MAX_SCHEME_LENGTH 32 // longest protocol name length
#define INTERNET_MAX_URL_LENGTH (INTERNET_MAX_SCHEME_LENGTH \
+ sizeof("://") \
+ INTERNET_MAX_PATH_LENGTH)
...
HttpOpenRequest does not have a maximum length but server software you are targeting will likely have a limit on your URL length.
Apache (Server)
My early attempts to measure the
maximum URL length in web browsers
bumped into a server URL length limit
of approximately 4,000 characters,
after which Apache produces a "413
Entity Too Large" error. I used the
current up to date Apache build found
in Red Hat Enterprise Linux 4. The
official Apache documentation only
mentions an 8,192-byte limit on an
individual field in a request.
Microsoft Internet Information Server (Server)
The default limit is 16,384 characters
(yes, Microsoft's web server accepts
longer URLs than Microsoft's web
browser). This is configurable.
Perl HTTP::Daemon (Server)
Up to 8,000 bytes will work. Those
constructing web application servers
with Perl's HTTP::Daemon module will
encounter a 16,384 byte limit on the
combined size of all HTTP request
headers. This does not include
POST-method form data, file uploads,
etc., but it does include the URL. In
practice this resulted in a 413 error
when a URL was significantly longer
than 8,000 characters. This limitation
can be easily removed. Look for all
occurrences of 16x1024 in Daemon.pm
and replace them with a larger value.
Of course, this does increase your
exposure to denial of service attacks.
(from Boutell.com)
I would suggest less than 2000 characters., but this KB article suggests Internet Explorer has a limit of 2083, which may well apply to your case too.