Is there a protocol that provides data integrity, but not encryption for HTTP?
SSL/TLS before 1.3 has some 'with-NULL' cipher suites that provide NO confidentiality, only authentication and integrity; see e.g. rfc5246 app C and rfc4492 sec 6 or just the registry. These do the usual handshake, authenticating the server identity using a certificate and optionally also the client identity, and deriving session/working keys which are used to HMAC the subsequent data (in both directions, not only from the server) but not to encrypt it. This prevents modification, or replay, but allows anyone on the channel/network to read it.
These cipher suites are very rarely used, and always (to the best of my knowledge) disabled by default. (In OpenSSL, they not only aren't included in DEFAULT but not even in the otherwise complete set ALL -- to get them you must specify (an) explicit suite(s), the set eNULL aka NULL, or the set COMPLEMENTOFALL, which last grates horribly to any mathematician!) I very much doubt you'll ever get any browser to use them, and probably not most apps or even many packaged servers. But if you control the apps at both ends of an HTTPS connection -- or perhaps proxies for the apps -- this does meet your apparent requirement.
TLS 1.3 changes how cipher suites are used, and no longer has this functionality. As time goes on, 1.3 will become more widespread, and it is likely 1.2 and 1.1 will be dropped in the foreseeable future. (1.0 already has been dropped many places, though not all. SSL3 is badly broken by POODLE, and dropped essentially everywhere.)
Yes, Signed Exchanges (SXG)
Such a mechanism does exist, although it is very new and somewhat controversial.
- SXGs are supported in Chromium browsers (Chrome 73, Edge 79, Opera 64).
- Mozilla considers SXGs harmful; Firefox does not support them.
- Safari does not support them. Apple has apparently expressed "skepticism" about the proposal, although I couldn't find anything authoritative.
SXGs are controversial because some view the proposal as an attempt by Google to impose a standard on the community in support of Google's also controversial AMP project. In short, SXGs were designed to allow browsers to display a publisher's URL in the URL bar even though the content was actually hosted by Google.
Editorial: This is a rather unfortunate situation since the proposal does have technical merits. While I do find AMP entirely distasteful, a spec that enables secure caching of HTTP resources at the LAN level is highly interesting. The SXG spec itself is also generic enough to be used in other use cases.
A SXG is a binary format that encapsulates a HTTP request and response (headers and payload) and signs it with a certificate issued to the origin domain. The SXG file is not encrypted and can be distributed in any way, including over plain HTTP or even on a flash drive.
The certificate used to sign a SXG is mostly similar to a standard X.509 cert used for HTTPS, but the cert must be issued by a trusted CA with a CanSignHttpExchanges extension if it is to be trusted by browsers. (These are not widely available yet.)
There could be, but is not
Such a protocol would be plausible. However, it does not have substantial advantages over HTTPS and there has not been a strong business need to facilitate the adoption of such a protocol, so it has not been implemented or adopted by the makers of mainstream browsers and servers.
It seems to me that the only use case for such a protocol would be in unusual niche conditions - so it seems appropriate that a custom niche protocol should be developed and used (likely by creating a modified version of open source servers and browsers) in scenarios where there is a desire for everyone in the network to see what each user is doing but still enforce authenticity of HTTP transfers; as this is an anti-feature for mainstream consumer use-cases.
I'd expect mainstream browsers to intentionally refuse including support for such a protocol, as the ability to downgrade user connections to a less secure option is considered as a security risk, and it's considered preferable to have security (including privacy) not as a default option, but as mandatory - users should not have an easy option to reduce security, as it would be abused. Certain aspects like that were proposed and discussed during the development of SSL/TLS/HTTPS standards, and intentionally left out of the final standard.