-
Notifications
You must be signed in to change notification settings - Fork 20
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
Set explicit HTTP Accept header to avoid text/html #40
Set explicit HTTP Accept header to avoid text/html #40
Conversation
see sbt/sbt#5483 |
d7e24c8
to
f5f00b0
Compare
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.
Thanks!
Does that mean it fixes sbt/sbt#5492 too, @3rwww1? |
@dwijnand Ever got a response to your question? :) |
No. But I'm leaning towards yes, because more often than not you hear back when it's still broken... 🙂 |
Re: sbt/sbt#5492, the issue is mostly about being able to resolve artifacts out of Azure DevOps Maven, so maybe tweaking Ivy might help for |
@dwijnand unfortunately I'm still not sure, I'm still jury-rigging around the issue with I'll try and test with coursier when I have some free time, I guess that all coursier need is to "set |
By default,
java.net.HttpURLConnection
HTTPAccept
header is set totext/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
This leads to Microsoft servers responding with a 203 status code and an HTML pages when uploading or downloading artifacts to Azure Artifacts.
Given that Maven also have a similar issue (
text/html
as the preferred response content-type), Microsoft has implemented a workaround that ignores theAccept
header values whenUser-Agent
isApache Maven/*
. However, this workaround is not implemented on their side for SBT.This pull request sets HTTP
Accept
header toapplication/octet-stream, application/json, application/xml, */*
to fix this behavior, as evidenced here:https://dev.azure.com/aironek/sbt-test/_build/results?buildId=43&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=b60649db-91ed-45ce-b0dd-c9633ee87772
Given that the last component is
*/*
, this shoud be backward-compatible with other serivces (Nexus, Artifactory, etc) that reply with different content-types.