Why webjobs api always returns “Accepted” status not 200 Ok
I am trying to run my azure web jobs through c# code but it works but it's return accepted status with 202 status code.
I am using below code for the same code snippet for webjob api call from web app.
c# api
azure webjob edited Dec 18 '18 at 6:06
Peter Pan
12.3k3824
asked Nov 26 '18 at 12:30
Dattatray PiseDattatray Pise
215
add a comment |
I am trying to run my azure web jobs through c# code but it works but it's return accepted status with 202 status code.
I am using below code for the same code snippet for webjob api call from web app.
c# api
azure webjob edited Dec 18 '18 at 6:06
Peter Pan
12.3k3824
asked Nov 26 '18 at 12:30
Dattatray PiseDattatray Pise
215
2
Instead of screenshot of the code, please include actual code in question.
– Gaurav Mantri
Nov 26 '18 at 12:33
4
Because a 200 would signal the job executed fine, while 202 would just indicate "okay, I hear you, let me see what I can do for you".
– Patrick Hofman
Nov 26 '18 at 12:35
A WebJob could potentially run for like half an hour. Azure would kill the connection before a response is sent.
– juunas
Nov 26 '18 at 12:37
You could show more code ,then we can test it or reproduce the problem.
– George Chen
Nov 27 '18 at 7:58
add a comment |
I am trying to run my azure web jobs through c# code but it works but it's return accepted status with 202 status code.
I am using below code for the same code snippet for webjob api call from web app.
c# api
azure webjob edited Dec 18 '18 at 6:06
Peter Pan
12.3k3824
asked Nov 26 '18 at 12:30
Dattatray PiseDattatray Pise
215
I am trying to run my azure web jobs through c# code but it works but it's return accepted status with 202 status code.
I am using below code for the same code snippet for webjob api call from web app.
c# api
azure webjob c# api
azure webjob edited Dec 18 '18 at 6:06
Peter Pan
12.3k3824
asked Nov 26 '18 at 12:30
Dattatray PiseDattatray Pise
215
edited Dec 18 '18 at 6:06
Peter Pan
12.3k3824
asked Nov 26 '18 at 12:30
Dattatray PiseDattatray Pise
215
edited Dec 18 '18 at 6:06
Peter Pan
12.3k3824
edited Dec 18 '18 at 6:06
Peter Pan
12.3k3824
edited Dec 18 '18 at 6:06
Peter Pan
12.3k3824
12.3k3824
asked Nov 26 '18 at 12:30
Dattatray PiseDattatray Pise
215
asked Nov 26 '18 at 12:30
Dattatray PiseDattatray Pise
215
asked Nov 26 '18 at 12:30
Dattatray PiseDattatray Pise
215
215
2
Instead of screenshot of the code, please include actual code in question.
– Gaurav Mantri
Nov 26 '18 at 12:33
4
Because a 200 would signal the job executed fine, while 202 would just indicate "okay, I hear you, let me see what I can do for you".
– Patrick Hofman
Nov 26 '18 at 12:35
A WebJob could potentially run for like half an hour. Azure would kill the connection before a response is sent.
– juunas
Nov 26 '18 at 12:37
You could show more code ,then we can test it or reproduce the problem.
– George Chen
Nov 27 '18 at 7:58
add a comment |
2
Instead of screenshot of the code, please include actual code in question.
– Gaurav Mantri
Nov 26 '18 at 12:33
4
Because a 200 would signal the job executed fine, while 202 would just indicate "okay, I hear you, let me see what I can do for you".
– Patrick Hofman
Nov 26 '18 at 12:35
A WebJob could potentially run for like half an hour. Azure would kill the connection before a response is sent.
– juunas
Nov 26 '18 at 12:37
You could show more code ,then we can test it or reproduce the problem.
– George Chen
Nov 27 '18 at 7:58
2
2
Instead of screenshot of the code, please include actual code in question.
– Gaurav Mantri
Nov 26 '18 at 12:33
Instead of screenshot of the code, please include actual code in question.
– Gaurav Mantri
Nov 26 '18 at 12:33
4
4
Because a 200 would signal the job executed fine, while 202 would just indicate "okay, I hear you, let me see what I can do for you".
– Patrick Hofman
Nov 26 '18 at 12:35
Because a 200 would signal the job executed fine, while 202 would just indicate "okay, I hear you, let me see what I can do for you".
– Patrick Hofman
Nov 26 '18 at 12:35
A WebJob could potentially run for like half an hour. Azure would kill the connection before a response is sent.
– juunas
Nov 26 '18 at 12:37
A WebJob could potentially run for like half an hour. Azure would kill the connection before a response is sent.
– juunas
Nov 26 '18 at 12:37
You could show more code ,then we can test it or reproduce the problem.
– George Chen
Nov 27 '18 at 7:58
You could show more code ,then we can test it or reproduce the problem.
– George Chen
Nov 27 '18 at 7:58
add a comment |
1 Answer
1
active
oldest
votes
It sounds like you may doubt that the HTTP response status code should be 200 OK, not 202 Accepted if a HTTP requst have been handled successfully. However, either 200 OK or 202 Accepted is legal and reasonable, please refer to the 10 section 10 Status Code Definitions of W3C RFC-2616 to know them in depth, as below.
10.2.1 200 OK The request has succeeded. The information returned with the response is dependent on the method used in the request, for
example:
GET an entity corresponding to the requested resource is sent in the
response;
HEAD the entity-header fields corresponding to the requested resource
are sent in the response without any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the end
server.
10.2.3 202 Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not
eventually be acted upon, as it might be disallowed when processing
actually takes place. There is no facility for re-sending a status
code from an asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist until
the process is completed. The entity returned with this response
SHOULD include an indication of the request's current status and
either a pointer to a status monitor or some estimate of when the user
can expect the request to be fulfilled.
Meanwhile, two code comments below from GitHub Kudu repo explain why used 202 Accepted for triggering webjobs in here.
I. Kudu.Services/ServiceHookHandlers/FetchHandler.cs#L111
// Return a http 202: the request has been accepted for processing, but the processing has not been completed.
II. Kudu.Services/Jobs/JobsController.cs#L191
// Return a 200 in the ARM case, otherwise a 202 can cause it to poll on /run, which we don't support
// For non-ARM, stay with the 202 to reduce potential impact of change
It's up to the design intent of services.
answered Dec 18 '18 at 6:27
Peter PanPeter Pan
12.3k3824
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53481181%2fwhy-webjobs-api-always-returns-accepted-status-not-200-ok%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
It sounds like you may doubt that the HTTP response status code should be 200 OK, not 202 Accepted if a HTTP requst have been handled successfully. However, either 200 OK or 202 Accepted is legal and reasonable, please refer to the 10 section 10 Status Code Definitions of W3C RFC-2616 to know them in depth, as below.
10.2.1 200 OK The request has succeeded. The information returned with the response is dependent on the method used in the request, for
example:
GET an entity corresponding to the requested resource is sent in the
response;
HEAD the entity-header fields corresponding to the requested resource
are sent in the response without any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the end
server.
10.2.3 202 Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not
eventually be acted upon, as it might be disallowed when processing
actually takes place. There is no facility for re-sending a status
code from an asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist until
the process is completed. The entity returned with this response
SHOULD include an indication of the request's current status and
either a pointer to a status monitor or some estimate of when the user
can expect the request to be fulfilled.
Meanwhile, two code comments below from GitHub Kudu repo explain why used 202 Accepted for triggering webjobs in here.
I. Kudu.Services/ServiceHookHandlers/FetchHandler.cs#L111
// Return a http 202: the request has been accepted for processing, but the processing has not been completed.
II. Kudu.Services/Jobs/JobsController.cs#L191
// Return a 200 in the ARM case, otherwise a 202 can cause it to poll on /run, which we don't support
// For non-ARM, stay with the 202 to reduce potential impact of change
It's up to the design intent of services.
answered Dec 18 '18 at 6:27
Peter PanPeter Pan
12.3k3824
add a comment |
It sounds like you may doubt that the HTTP response status code should be 200 OK, not 202 Accepted if a HTTP requst have been handled successfully. However, either 200 OK or 202 Accepted is legal and reasonable, please refer to the 10 section 10 Status Code Definitions of W3C RFC-2616 to know them in depth, as below.
10.2.1 200 OK The request has succeeded. The information returned with the response is dependent on the method used in the request, for
example:
GET an entity corresponding to the requested resource is sent in the
response;
HEAD the entity-header fields corresponding to the requested resource
are sent in the response without any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the end
server.
10.2.3 202 Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not
eventually be acted upon, as it might be disallowed when processing
actually takes place. There is no facility for re-sending a status
code from an asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist until
the process is completed. The entity returned with this response
SHOULD include an indication of the request's current status and
either a pointer to a status monitor or some estimate of when the user
can expect the request to be fulfilled.
Meanwhile, two code comments below from GitHub Kudu repo explain why used 202 Accepted for triggering webjobs in here.
I. Kudu.Services/ServiceHookHandlers/FetchHandler.cs#L111
// Return a http 202: the request has been accepted for processing, but the processing has not been completed.
II. Kudu.Services/Jobs/JobsController.cs#L191
// Return a 200 in the ARM case, otherwise a 202 can cause it to poll on /run, which we don't support
// For non-ARM, stay with the 202 to reduce potential impact of change
It's up to the design intent of services.
answered Dec 18 '18 at 6:27
Peter PanPeter Pan
12.3k3824
add a comment |
It sounds like you may doubt that the HTTP response status code should be 200 OK, not 202 Accepted if a HTTP requst have been handled successfully. However, either 200 OK or 202 Accepted is legal and reasonable, please refer to the 10 section 10 Status Code Definitions of W3C RFC-2616 to know them in depth, as below.
10.2.1 200 OK The request has succeeded. The information returned with the response is dependent on the method used in the request, for
example:
GET an entity corresponding to the requested resource is sent in the
response;
HEAD the entity-header fields corresponding to the requested resource
are sent in the response without any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the end
server.
10.2.3 202 Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not
eventually be acted upon, as it might be disallowed when processing
actually takes place. There is no facility for re-sending a status
code from an asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist until
the process is completed. The entity returned with this response
SHOULD include an indication of the request's current status and
either a pointer to a status monitor or some estimate of when the user
can expect the request to be fulfilled.
Meanwhile, two code comments below from GitHub Kudu repo explain why used 202 Accepted for triggering webjobs in here.
I. Kudu.Services/ServiceHookHandlers/FetchHandler.cs#L111
// Return a http 202: the request has been accepted for processing, but the processing has not been completed.
II. Kudu.Services/Jobs/JobsController.cs#L191
// Return a 200 in the ARM case, otherwise a 202 can cause it to poll on /run, which we don't support
// For non-ARM, stay with the 202 to reduce potential impact of change
It's up to the design intent of services.
answered Dec 18 '18 at 6:27
Peter PanPeter Pan
12.3k3824
It sounds like you may doubt that the HTTP response status code should be 200 OK, not 202 Accepted if a HTTP requst have been handled successfully. However, either 200 OK or 202 Accepted is legal and reasonable, please refer to the 10 section 10 Status Code Definitions of W3C RFC-2616 to know them in depth, as below.
10.2.1 200 OK The request has succeeded. The information returned with the response is dependent on the method used in the request, for
example:
GET an entity corresponding to the requested resource is sent in the
response;
HEAD the entity-header fields corresponding to the requested resource
are sent in the response without any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the end
server.
10.2.3 202 Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not
eventually be acted upon, as it might be disallowed when processing
actually takes place. There is no facility for re-sending a status
code from an asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist until
the process is completed. The entity returned with this response
SHOULD include an indication of the request's current status and
either a pointer to a status monitor or some estimate of when the user
can expect the request to be fulfilled.
Meanwhile, two code comments below from GitHub Kudu repo explain why used 202 Accepted for triggering webjobs in here.
I. Kudu.Services/ServiceHookHandlers/FetchHandler.cs#L111
// Return a http 202: the request has been accepted for processing, but the processing has not been completed.
II. Kudu.Services/Jobs/JobsController.cs#L191
// Return a 200 in the ARM case, otherwise a 202 can cause it to poll on /run, which we don't support
// For non-ARM, stay with the 202 to reduce potential impact of change
It's up to the design intent of services.
answered Dec 18 '18 at 6:27
Peter PanPeter Pan
12.3k3824
answered Dec 18 '18 at 6:27
Peter PanPeter Pan
12.3k3824
answered Dec 18 '18 at 6:27
Peter PanPeter Pan
12.3k3824
answered Dec 18 '18 at 6:27
Peter PanPeter Pan
12.3k3824
12.3k3824
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53481181%2fwhy-webjobs-api-always-returns-accepted-status-not-200-ok%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Instead of screenshot of the code, please include actual code in question.
– Gaurav Mantri
Nov 26 '18 at 12:33
4
Because a 200 would signal the job executed fine, while 202 would just indicate "okay, I hear you, let me see what I can do for you".
– Patrick Hofman
Nov 26 '18 at 12:35
A WebJob could potentially run for like half an hour. Azure would kill the connection before a response is sent.
– juunas
Nov 26 '18 at 12:37
You could show more code ,then we can test it or reproduce the problem.
– George Chen
Nov 27 '18 at 7:58