我有一个带有GraphQL端点的Rails应用，该端点可以接收大量数据。一个帖子可以轻松达到500Kb。我碰到了FILE * Fchoice = fopen(Addresses, "r+");
fscanf(Fchoice ,"%[^\n]s\n%[^\n]s\n%d\n%d\n%d\n%[^\n]s%d\n%d\n%d",
TmpProblem.question, // char[]
TmpProblem.choices[0].what, // char[]
&TmpProblem.choices[0].people, // int
&TmpProblem.choices[0].court, // int
&TmpProblem.choices[0].treasury, // int
TmpProblem.choices[1].what, // char[]
&TmpProblem.choices[1].people, // int
&TmpProblem.choices[1].court, // int
&TmpProblem.choices[1].treasury // int
);
;
key_space_limit
但是，如果API用户超出512kb的限制，我想给他们一个有用的错误。目前，这是一个Rack::Utils.key_space_limit = 8 * 65536，并不理想。
我尝试在graphql控制器中营救500 Internal Server Error
RangeErrors但是我仍然得到def execute
...
rescue RangeError => e
render json: { error: { message: "message too large, please limit messages to 512Kb"}, data: {} }, status: 400
end
;
RangeError我也无法在控制器测试中重复该问题。该测试不会失败，就像在开发或生产中运行一样；
2019-01-14 13:04:23 -0500: Rack app error handling request { POST /graphql }
#<RangeError: exceeded available parameter key space>
我假设错误的发生级别高于控制器。我知道增加test "large posts should work" do
request.headers['HTTP_ACCESS_TOKEN'] = @biometric_token.token
lots_of_biometrics = ''
10000.times do
lots_of_biometrics += '''
{
value: 80
type: weight
source: "really long string that take up loads of space because"
notes: "another really long string because we are testing large posts to the graphql endpoint"
},
'''
end
large_query = """
mutation {
BulkCreate(
biometrics: [#{lots_of_biometrics}]
) {
id
records_total
}
}
"""
Sidekiq::Testing.inline! do
post :execute, format: :json, body: large_query
end
body = JSON.parse(response.body)
assert_response :success
end
会导致DDoS风险，因此我认为这是设计使然。但是，有人对API用户超出限制时做出有用的响应有何建议？