Support handling 304 status code in onResponse flow #119
Conversation
| @@ -30,6 +30,16 @@ class DioCacheInterceptor extends Interceptor { | |||
|
|
|||
| final cacheOptions = _getCacheOptions(options); | |||
|
|
|||
| if (cacheOptions.callResponseInterceptorsAfterNotModified) { | |||
There was a problem hiding this comment.
Why do you need this? Can we get rid of callResponseInterceptorsAfterNotModified?
If RequestOptions has a custom validateStatus which allows 304 as valid there should be nothing to do here.
There was a problem hiding this comment.
I added this because using validateStatus to validate 304's is not transparent to me. You would have to look into the source code of this cache interceptor to know how 304's are handled. Ofcourse this is more an issue with dio (handling not valid responses in onError and never going back to the onResponse flow) and it breaks every other response interceptor.
| @@ -83,6 +93,29 @@ class DioCacheInterceptor extends Interceptor { | |||
| return; | |||
| } | |||
|
|
|||
| // Check if cache response should be used instead of server response | |||
There was a problem hiding this comment.
Fair. I will create a method for this.
* PR feedback * Added test for 304 in success response
|
Updated Pull request with master and requested changes. |
|
I forgot to remove the field |
|
Thanks for your contribution. This PR has been reworked internally and is now available in v3.5.0. |
In Dio a
304 not modifiedcan be configured to be a valid status:BaseOptions(validateStatus: (status) => status != null && ((status >= 200 && status < 300) || status == 304))This PR allows 304's to be handled in the onResponse flow.
This way (having not modified as a valid status) the usual chain of onResponse interceptors will still trigger, unlike the error flow.