-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: respect resource mime type in responses #170
Conversation
9dec4ba
to
83a3853
Compare
83a3853
to
2c3a283
Compare
The server was ignoring mime types set on resources, defaulting to text/plain for strings and application/octet-stream for bytes. Now properly preserves the specified mime type in both FastMCP and low-level server implementations. Note that this is breaks backwards compatibility as it changes the return values of read_resource() on FastMCP. It is BC compatible on lowlevel since it only extends the callback. Github-Issue: #152 Reported-by: eiseleMichael
Update README examples to show proper handling of the new read_resource() return value that includes mime type information. Github-Issue:#152
89eca5b
to
f90cf6a
Compare
|
||
- For commits related to a Github issue, add | ||
```bash | ||
git commit --trailer "Github-Issue:#<number>" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
git commit --trailer "Github-Issue:#<number>" | |
git commit --trailer "GitHub-Issue:#<number>" |
I think we should make this follow the spec more closely if we're going to break backwards compatibility anyway. |
Introduce ReadResourceContents type to properly handle MIME types in resource responses. Breaking change in FastMCP read_resource() return type. Github-Issue:#152
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about multiple result values, per my comment?
I thought about it, but honestly, i want to converge to one return value so people dont have to match on the return value. I chose the current appraoch as I want to keep lowlevel fairly BC compatible until v2.0.0 but I am okay changing the higher level FastMCP return value around, since its a bit more faster moving for 1.3.0. |
Summary
Notable this is a BC breaking change due to the new return values in
read_resource()
on FastMCP.Test plan