Guild Wars 2

Okay so this one. Cool. Now let’s update the API so that it throws a non-redundant redundancy error.

You are asking 40 times for the SAME egg which remains 1. I’m out.

Don’t go yet, I have more riddles for you to solve!

Have a stab at this one:
/v2/eggs?ids=yellow,yellow,green,yellow,red,blue,yellow,yellow

What is the output? You have 5 minutes to solve this quiz.

My 2 cents regarding cloned Quaggans:
API should not waste resource printing duplicate items (Quaggans are 35, but what happen when you have to search in 36000 items?). I think that it should check for duplicate, if duplicates are found it should throw an error with a 302 HTTP redirect to the list of same objects without duplicates.
In this way error is thrown, and is also very easy to correct the wrong request (that is very helpful if list are hand-written).
It is also a solution accessible, and easly applicable, by (I think) all endpoints.

I like that idea. There’s also HTTP 303 “See Other”. It is similar to HTTP 302, but with a subtle difference that makes it more suitable:

A 303 response to a GET request indicates that the origin server does
not have a representation of the target resource that can be
transferred by the server over HTTP. However, the Location field
value refers to a resource that is descriptive of the target
resource, such that making a retrieval request on that other resource
might result in a representation that is useful to recipients without
implying that it represents the original target resource.

Source: https://tools.ietf.org/html/rfc7231#section-6.4.4

https://api.guildwars2.com/v2/commerce/listings doesnt send X-Result-Count and X-Result-Total headers like the quaggan API

Interesting. Could that be intended? The actual count depends on how players interact with the game, so I wouldn’t be surprised.

I don’t think its intended, when accessing https://api.guildwars2.com/v2/commerce/listings?page=1000 (page out of range), it tells you how many pages there are, so the information is definitely there.

/v2/commerce/listings returns literal “null” strings when a bulk request specifies non-existent or account-bound item identifiers.

https://api.guildwars2.com/v2/commerce/listings?ids=-2,-3,6,24

You might have to refresh the page a couple of times to see it.

I tried two different serialization engines, and both fail to correctly recognize these values as null.

Might turn this one in over here: https://forum-en.gw2archive.eu/forum/community/api/Match-details-giving-incorrect-results/4436632

Are there any plans to fix the unlock type for outfits?

https://api.guildwars2.com/v2/items?ids=64756,64754,65198,65201,65194,65195,65196,66279,66658,67040

Pat Cavit.9234:

StevenL.3761:

/v2/commerce/listings returns literal “null” strings when a bulk request specifies non-existent or account-bound item identifiers.

https://api.guildwars2.com/v2/commerce/listings?ids=-2,-3,6,24

You might have to refresh the page a couple of times to see it.

I tried two different serialization engines, and both fail to correctly recognize these values as null.

We’re taking a look at this and have a plan for how to fix. That’s a fun one, good catch!

It’s better now, but there are still some inconsistencies that make my code crash.

Right now, the listings service returns garbage values instead of an error for some identifiers:

OK: https://api.guildwars2.com/v2/commerce/listings/0
Not OK: https://api.guildwars2.com/v2/commerce/listings/1

Same story for the prices service.

OK: https://api.guildwars2.com/v2/commerce/prices/0
Not OK: https://api.guildwars2.com/v2/commerce/prices/1

I can’t check on my phone, but I don’t believe that ID 1 returns an error code. Just HTTP 200 and a garbage value.

I’m not sure if this is even worth looking at, but there’s still that bug where IIS crashes with a text/html response when the parameter list gets too big. Probably because IIS/ARR and the private API do not agree on the maximum URL length.

Example: http://pastebin.com/nXSR8kSb

StevenL.3761:

I’m not sure if this is even worth looking at, but there’s still that bug where IIS crashes with a text/html response when the parameter list gets too big. Probably because IIS/ARR and the private API do not agree on the maximum URL length.

Example: http://pastebin.com/nXSR8kSb

The only problem I see in that request is that the server reply with a 404 error instead of 414 error. The URL is 2215 character long, it should be less than 2000, and the request is to have 550 items where you should only request 200. I think that you cannot have a json reply in this case, because in my opinion your request is stopped and rejected by IIS, it never reach API level. I don’t know IIS, but this response is seems to me like error page configured in apache, in this case when apache read the request, it reject it and reply with its default error page (in this case reply with a 404 error, but it should reply with 414 error) that it’s a plain html file similar to all error page saw in GW2 web services. Probably they never thought that they need a 414 page error (for a normal web service like website or forum is really uncommon to have url length problem) and didn’t created that page error, so the server reply with a default 4xx error.

I think this behavior is caused by a setting in the Request Filtering module (http://www.iis.net/configreference/system.webserver/security/requestfiltering). The article perfectly matches the behavior that I’m seeing.

When request filtering blocks an HTTP request, IIS 7 will return an HTTP 404 error to the client and log the HTTP status with a unique substatus that identifies the reason that the request was denied.

So, to disable the filter:

• Open IIS Manager and connect to the gateway server that routes the requests
• Click the root node of the server in the “Connections” panel
• Double click “Request filtering” in the “Features View” panel
• Click “Edit Feature Settings…” in the “Actions” panel
• Change the maximum URL and query string length to 4294967295 (max), or something more sensible than 2048/4096

I can stop a user from passing more than 200 identifiers, but I can’t stop a user from passing 200 times the maximum value for a 32 bit integer (2147483647). The precision here is 10, so that alone adds up to 2000 characters. That’s still less than 2048, but then you’re forgetting about the delimiters.

If you’re passing a user through to the API, it’s generally considered your responsibility to either guide them through it or stop it from sending stuff you know won’t work and will cause technical problems. Which means either you count up the commas and validate or you just strip off whatever gets passed through after the last comma from your server request when the query string hits the limit.

Just my own opinion on the matter. It definitely should be adjusted to show the correct error at some point, but in terms of the actual effect , it’s pretty negligable. You know you can only get 200 items back, so you should write to that reality anyway.

Having client side validation is good. Only having client side validation is bad. Our library comes with options to disable parameter validation in release mode (to save some CPU cycles), so there will still be times when a user passes some ridiculous value that doesn’t work, but doesn’t actually violate the protocol.

StevenL.3761:

Having client side validation is good. Only having client side validation is bad. Our library comes with options to disable parameter validation in release mode (to save some CPU cycles), so there will still be times when a user passes some ridiculous value that doesn’t work, but doesn’t actually violate the protocol.

It’s sound simple to me, when you have a not HTTP 200 response from the server trow an exception to the user and force a client side validation. You should simply stop when you don’t get an 200 response from the server. 414 error instead of 404 it’s a semanthic problem, you should everytime stop when not receiving an HTTP 200 reply from the server, regardless of the exactly error you get.

Guys, the problem was never the status code. The problem is the text/html content-type along with the HTML body.

if (!response.StatusCode.IsSuccessStatusCode())
{
	if (response.ContentType.StartsWith("application/json"))
	{
		// Throw an exception with a meaningful error description
	}
	else
	{
		// Crash with a meaningless error description, because the content-type is not JSON
	}
}

You cannot have a json response from the API if the API cannot read your request. Your request is stopped by ISS, API never know that you made a request.
If you get a 4xx error, you have to understand why your request is wrong, not why you dont receive an extensive response from the server that explain why your request is wrong.

In this case your request have 2 errors, url is longer than maximum allowed, and you are requesting more than double (550) of max number of items requestable in a single request (200).
Here the problem is in your request, not in the reply from the server, you should be sure to not do such type of request, because you know that those requests are not allowed.

Check if the response code is between 399 and 500, if yes your request should be cleaned.

Let’s break this down into manageable chunks.

Alcarin.9024:

You cannot have a json response from the API if the API cannot read your request. Your request is stopped by ISS, API never know that you made a request.

This behavior is caused by a security feature that can be disabled. I’m not trying to steal your data, so why this has to be enabled is beyond me.

Alcarin.9024:

If you get a 4xx error, you have to understand why your request is wrong, not why you dont receive an extensive response from the server that explain why your request is wrong.

The request isn’t necessarily wrong. Look at /v1/world_names.json. It returns a 4xx code even though the request is perfectly fine.

Alcarin.9024:

In this case your request have 2 errors, url is longer than maximum allowed, and you are requesting more than double (550) of max number of items requestable in a single request (200).

Really think about why we should get a proper error response for 201 IDs, but not for 550 IDs. What is the difference? I’d be glad to hear it.

Alcarin.9024:

Here the problem is in your request, not in the reply from the server, you should be sure to not do such type of request, because you know that those requests are not allowed.

You have to draw a line somewhere between what is and isn’t violating the interface. Sending more than 200 IDs is disabled for many good reasons, but it is nevertheless a syntactically and semantically well-formed request. Responding with text/html when the protocol is to respond with application/json however is a clear violation.

We are really going OT…

StevenL.3761:

Alcarin.9024:

You cannot have a json response from the API if the API cannot read your request. Your request is stopped by ISS, API never know that you made a request.

This behavior is caused by a security feature that can be disabled. I’m not trying to steal your data, so why this has to be enabled is beyond me.

I manage a server and I’ll never disable this feature:
1) URLs long than 2000 characters are useless, you are doing something wrong if you need them (in example you should use POST instead of GET request).
2) It’s a security feature, I don’t work in server security (I only try to secure my server), but if someone think that this is a security feature there should be good reasons. I can speculate that GET headers requests are stored in ram until they are completly received (POST should be directly writed to disk I think). When a GET request exceed a certain amount of data, the server stop to accept the request and reply with an error. The client may continue to send the request, but the server drop any further data coming from that request. Disabling such a feature will force the server to wait (and load in ram) the entire request before thinking of a reply. What will happen if you send 2000 simultaneously request each with 200000000 characters with this security feature disabled? The server start to load each request in ram, and wait until each request is completly received, server will start to have ram problem very soon, will start to use swap, will slow down, and will crash if such type of request continue to come. The results are that it’s not necessary a lot of bandwidth to crash a server, it’s only needed that you send multiple request at the same time. So disabling this feature will let GW2 API server be very vulnerable to DOS attacks, that in this case may cause a server crash, not only a service interruption.

It’s never a good idea to disable a security feature, expecially if it is enabled by default.

StevenL.3761:

Alcarin.9024:

If you get a 4xx error, you have to understand why your request is wrong, not why you dont receive an extensive response from the server that explain why your request is wrong.

The request isn’t necessarily wrong. Look at /v1/world_names.json. It returns a 4xx code even though the request is perfectly fine.

World name is disabled. It’s the API level that reply with a 404 error, not IIS, it’s a lot different.
Anyway, 404 is a wrong error in this case, maybe 403 is better, but it’s still a semantics problem. The really important thing is that there is a problem with your request, in this case you should not request for world_names.json, because it is disabled.

StevenL.3761:

Alcarin.9024:

In this case your request have 2 errors, url is longer than maximum allowed, and you are requesting more than double (550) of max number of items requestable in a single request (200).

Really think about why we should get a proper error response for 201 IDs, but not for 550 IDs. What is the difference? I’d be glad to hear it.

Because they are two really different problem.
With 201 items you will not get a reply from the Database, because it will require too much time and database resource (developer decided that 201 items request are not acceptable).
With 550 item, it’s not a problem that you are requesting 550 items, the problem is that your request URL is too long, your request is not acceptable from the IIS server because may be a security issue (I guess that may overcharge server ram), you will not get a reply from the API (that could reply in JSON that 550 items are too much). The request is stopped by IIS, API never know that you made such request. How could API reply if it doesn’t know that you ever made a request?

I hope that this little schema will let you understand, normaly request come from the top, go until bottom and then come back to the top.

    Client
         |
        IIS      2215 URL length request stop here, don't  go down
         |
      API      201 items request stop here, don't go down
         |
 DataBase  less than 201 items request come here and go back to top
 

API talk with json, IIS talk with predefined error file (in this case we don’t have a 414 error file, so we get a 404 instead)

StevenL.3761:

Alcarin.9024:

Here the problem is in your request, not in the reply from the server, you should be sure to not do such type of request, because you know that those requests are not allowed.

You have to draw a line somewhere between what is and isn’t violating the interface. Sending more than 200 IDs is disabled for many good reasons, but it is nevertheless a syntactically and semantically well-formed request. Responding with text/html when the protocol is to respond with application/json however is a clear violation.

API request will get a JSON reply as much as your request reach the API, to let your request reach the API you MUST do request with less than 2000 characters. As much as you request less than 500 items be assured that you will receive a JSON error, if you exceed 500 items you cannot get a JSON reply.
So the limit to get a JSON reply, is something near 500 items, try with 500 items and you get a JSON reply, try with more than about 2000 characters and you will get a standar erro page.

I understand that those thing are not easy to understand, but your request (have always JSON reply) is not really applicable. I hope now you understand why.

The one thing nobody has addressed so far is the 10 digit precision problem.

I can devise a request that passes validation for every rule in place right now:

• No more than 200 identifiers
• All identifiers are numeric, 32 bit integers
• No two identifiers are the same

…yet my request will result in a crash.

http://pastebin.com/Pipvc4VS

I understand perfectly well why this is happening. You need to understand why this shouldn’t be happening. Not unless you introduce another validation rule that invalidates my request regardless of the maximum allowed query string. But what sort of rule would that be?

Keep in mind that they have to be API-level validation rules. That means forget that the query string even existed before it reached the API. So no checking for length.

Ok, so the problem is that you cannot verify your url once it is generated (this is another problem, that have nothing to do with API programming!).
In that case you could simply check if items ids are numeric, 32 bit integers, and less than 100000 (max known id is 67359, you will get a too long url with more than 500 items with 5 character each).
I don’t know what programming language you are using, but you could get the integer part of id mod 100000 and you get a “valid” id, or at last you cannot generate an url longer than allowed in that way.

It’s just weird having to write workarounds for limitations that exist only at the transport level. Validation should only occur at the API level. And for that purpose, it shouldn’t matter if the request is encoded as a query string, or flown into the office on a piece of paper by a carrier pidgeon.

You could just split the request of too many items up into multiple requests and join them into one collection before returning them to the user.
But the RFC 2616 (3.2.1) says “The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs.” So the API really should be able to handle a request of 200 32bit Integers, so 2000 + the length of the endpoint url.

The maximum length of a valid query string is exactly 2207 bytes.

• 2000 bytes for the total length of all IDs combined
• 199 bytes for the delimiters
• 8 bytes for the optional “&lang=xx” parameter

Valid in the sense that it satisfies all preconditions. Not valid in the sense that any of the IDs actually exist. So the filter should be adjusted from 2048 to 2207. The power of RFC 2616 compels you!

If I drink 1,5l of milk each day, I have to buy 2 bottle of 1l of milk, maybe I’m wrong, but I’m not used to complain that the milk producer must produce 1,5l bottle.
If you ask to item api about an item, you will get that item info, if you send junk to item api you will get an error, if you send junk to item api server, you get an http error.
It is your responsability to send a correct and understandable request to the api, you cannot complain with developers because you are not able/don’t want to clean your request.
This is what we have, and I really hope that developers don’t waste their time creating single error for every junk request they get, I hope that they spent their time developing new features instead.

200 items with id of 32 bit it’s not a valid request, items id are at maximum 17 bit long, not 32, you must provide a list of 17 bits ids, not 32 bits id.
Items api is able to reply at a list of 200 items id (17 bits each), there is no point in adjusting allowed url length server side.

Sanitize your requests, and you get no problem at all.

Guys, please stop derailing this thread. It has been pinned for a reason and was not meant to be a discussion thread.

(can someone please merge the discussion stuff into new topics?)

That’s not how that works. There is no numeric data type that uses 17 bits in any programming language that I know of. The next step up from 16 bit is usually 32 bit, so you have to design for that. Furthermore, my request respects every precondition that is imposed by the API. What about my request makes it “junk”? The fact that my identifiers don’t exist? Maybe I know that, but my code doesn’t.

Hi. Seems to be a bug with the mumble link coordinates in the latest patch. The x coordinates are displaced a bit to the right. Anyone notice?

I don’t know if this has been posted but if you are grabbing a page at a time it will break around page 195 if your page size is 200.

for example: https://api.guildwars2.com/v2/items?page=195&page_size=200

I tried dropping it to page_size 150 but it breaks later on, I’m still testing not passing in a page size which seems to be returning 50 by default.

If I were to guess what the problem is, I’d say it’s how you’re joins are working in a x to many situation or multiple x to many situation. I usually handle these by sub queries or separate queries depending on the backend API available.

Never mind it looks like that only occurs on the last page. I wish there was a call or a way to get the number of pages based on page size or some semblance of meta data. Right now I am actually capturing the 400 error and stopping once I receive it.

Ruggs.8420:

I wish there was a call or a way to get the number of pages based on page size or some semblance of meta data.

There is the X-Page-Total Header

darthmaim.6017:

Ruggs.8420:

I wish there was a call or a way to get the number of pages based on page size or some semblance of meta data.

There is the X-Page-Total Header

Wow, now I feel doubly stupid. Thanks.

Stefan Larimore.6872:

I finally fixed the problem with the missing items, recipes, events from the previous reset we had about a month ago. I was hoping they would get re-discovered, but as people noticed this wasn’t happening in a timely fashion. It wasn’t a trivial thing to re-seed this, but it is done now. Let me know if you are still noticing anything missing. Thank you.

Some items seem to be missing. For example “Hero’s Dagger”(64288), seems to be missing while “Hero’s Axe”(64287) is there.
But “Mists Stone”(67007) and “Resonating Chaos Orb”(66983) seem to be missing, too.
Additionaly “Master’s Salvage Kit”(23043) is nowhere to be found.
Did I miss something, has nobody “discovered” these items or is there some kind of error for getting the IDs (via wiki)?

PS: jsfiddle example
PPS: At least I’m not the only one missing some items

@peterpat: There are various systems in the game that have to “report” items to the API as being “discovered.” There are still some gaps in these systems where they fail to report items correctly.

(You’d think it would be as simple as a check on the inventory: whenever an item is added to any character’s inventory, report that item to the API. But apparently it’s not that simple.)

Is there any issue / or is there anyone meeting an issue with the property “name” from /v2/items ?
I still have one error (impossible to read property “name”) since some days and I had no problem before with my code and it is fine if I use the gw2Spidy data.

Some items are now appearing with “/n” (newline) as part of their name. Specific examples being:
https://api.guildwars2.com/v2/items/24863?lang=de
https://api.guildwars2.com/v2/items/24864?lang=de
https://api.guildwars2.com/v2/items/24865?lang=de

Lawton Campbell.8517:

…huh, that’s super weird. I’ll see if I can fix that next week.

Just add a trim() But it looks like that it is mainly a localization error as the line break is visible in-game, too. Probably somebody pressed enter while entering the data where he wasn’t supposed to press enter

What a stupid Sticky Topic.
I don’t mean the original Topic/Post is stupid, the original Topic/Post is OK.
It’s the fact you made it into a Sticky is silly.
It’s going to end up as a Topic with a thousand pages you have to search through.

I would Class API errors & bugs as a Category not a Topic

If you want all errors Topics in one place create a sub-forum.

http://en.wikipedia.org/wiki/Internet_forum
Read: Structure, Thread and Stickying

or

Tag the Title of a Topics when you create one.
i.e.
v1/item_details.json[Error]

Having each in a separate Topic enables the Topic to be close deleted or archived when it is no longer required.

Reading though pages of text to find something you may be able to help with is hard and boring. Then when you find some thing, you have to read through the rest of the pages to see if it has been sorted or not.