Aren/haiku
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
ba3ee26af0
haiku/headers/private/netservices/HttpResult.h

77 lines
1.5 KiB
C
Raw Normal View History

Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
/*
libbnetapi: fix access to HTTP headers The asynchronous listener had no reliable way to access HTTP result and headers from the callbacks. As the callbacks are triggered asynchronously, they can be run after the request has carried on and, for example, followed an HTTP redirect, clearing its internal state. The HeadersReceived callback now passes a reference to BUrlResult for the request. There are two cases: - Synchronous listener: passes a reference to the request's results directly - Asynchronous listener: archives a copy of the result into the notification message, and passes a reference to the unarchived copy. Unfortunately this comes with several ABI and API breakages: - Change to the prototype of HeadersReceived() - Change to the class hierarchy of BUrlResult (implements BArchivable) All users of HTTP requests will need to be updated if they implemented in HeadersReceived or used BUrlResult.
2017-01-29 21:25:02 +03:00
* Copyright 2010-2017 Haiku Inc. All rights reserved.
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
* Distributed under the terms of the MIT License.
*/
Reintroduce BUrlResult and add BDataRequest * BUrlResult is back, with ContentType and Length methods. * BHttpResult subclasses it and use HTTP header fields to implement those * Introduce BDataRequest for "data" URIs. These embed the data inside the URI, either as plaintext or base64 encoded.
2013-12-09 23:26:13 +04:00
#ifndef _B_HTTP_RESULT_H_
#define _B_HTTP_RESULT_H_
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
#include <HttpHeaders.h>
#include <String.h>
#include <Url.h>
Reintroduce BUrlResult and add BDataRequest * BUrlResult is back, with ContentType and Length methods. * BHttpResult subclasses it and use HTTP header fields to implement those * Introduce BDataRequest for "data" URIs. These embed the data inside the URI, either as plaintext or base64 encoded.
2013-12-09 23:26:13 +04:00
#include <UrlResult.h>
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
libnetservices.a: Put the experimental API into BPrivate::Network namespace In order to prevent classes between libnetapi.so with the legacy API and applications using the libnetservices.a library, the latter will have the classes in a distinct namespace. In the implementation, both libbnetapi.so and libnetservices.a will use the same header and source files. If LIBNETAPI_DEPRECATED is defined during build, the headers and source will have binary compatible behavior. Otherwise, the classes and other objects will be put in the HaikuExt namespace. In order to build the libbnetapi.so and libnetservices.a with the proper build configuration, there is a stub `src/kits/net/libnetapi_deprecated` folder that applies the special configuration to the source files. Currently HaikuDepot, Webpositive, libshared.a and the http_streamer add on use the compatible API in libbnetapi.so. Change-Id: Ic73e9f271ef75749adda46f6f72e9a0b2851b461 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3667 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2021-01-22 17:20:19 +03:00
#ifndef LIBNETAPI_DEPRECATED
namespace BPrivate {
namespace Network {
#endif
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
class BUrlRequest;
Reintroduce BUrlResult and add BDataRequest * BUrlResult is back, with ContentType and Length methods. * BHttpResult subclasses it and use HTTP header fields to implement those * Introduce BDataRequest for "data" URIs. These embed the data inside the URI, either as plaintext or base64 encoded.
2013-12-09 23:26:13 +04:00
class BHttpResult: public BUrlResult {
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
friend class BHttpRequest;
libbnetservices: BUrlResult is no longer a BArchivable The switch to make BUrlResult serializable was debuted in f9e1854f198d4200f21a9cbe29fdfb0fabbe192f with the rationale is that BHttpRequest auto-redirection might cause the headers to become obsolete by the time a client process the BMessage received from BUrlProtocolDispatchingListener. With the change to BHttpRequest to not notify listeners when auto-redirection is enabled, this is no longer the case and the serialization code can go away now. This simplifies BUrlResult and its subclasses, and gain us some performance for clients using BUrlProtocolDispatchingListener as the result object no longer has to be serialized. This also change the ABI of BUrlProtocolListener::HeadersReceived to no longer passing a BUrlResult. Additionally, BUrlResult and BHttpResult now express the size of the content as an off_t, thus allowing results larger than 4 GB. Change-Id: I9dd29a8b26fdd9aa8e5bbad8d1728084f136312d Reviewed-on: https://review.haiku-os.org/c/haiku/+/3082 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-07-18 06:58:55 +03:00
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
public:
BHttpResult(const BUrl& url);
libbnetservices: BUrlResult is no longer a BArchivable The switch to make BUrlResult serializable was debuted in f9e1854f198d4200f21a9cbe29fdfb0fabbe192f with the rationale is that BHttpRequest auto-redirection might cause the headers to become obsolete by the time a client process the BMessage received from BUrlProtocolDispatchingListener. With the change to BHttpRequest to not notify listeners when auto-redirection is enabled, this is no longer the case and the serialization code can go away now. This simplifies BUrlResult and its subclasses, and gain us some performance for clients using BUrlProtocolDispatchingListener as the result object no longer has to be serialized. This also change the ABI of BUrlProtocolListener::HeadersReceived to no longer passing a BUrlResult. Additionally, BUrlResult and BHttpResult now express the size of the content as an off_t, thus allowing results larger than 4 GB. Change-Id: I9dd29a8b26fdd9aa8e5bbad8d1728084f136312d Reviewed-on: https://review.haiku-os.org/c/haiku/+/3082 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-07-18 06:58:55 +03:00
#ifdef LIBNETAPI_DEPRECATED
libbnetapi: fix access to HTTP headers The asynchronous listener had no reliable way to access HTTP result and headers from the callbacks. As the callbacks are triggered asynchronously, they can be run after the request has carried on and, for example, followed an HTTP redirect, clearing its internal state. The HeadersReceived callback now passes a reference to BUrlResult for the request. There are two cases: - Synchronous listener: passes a reference to the request's results directly - Asynchronous listener: archives a copy of the result into the notification message, and passes a reference to the unarchived copy. Unfortunately this comes with several ABI and API breakages: - Change to the prototype of HeadersReceived() - Change to the class hierarchy of BUrlResult (implements BArchivable) All users of HTTP requests will need to be updated if they implemented in HeadersReceived or used BUrlResult.
2017-01-29 21:25:02 +03:00
BHttpResult(BMessage*);
libbnetservices: BUrlResult is no longer a BArchivable The switch to make BUrlResult serializable was debuted in f9e1854f198d4200f21a9cbe29fdfb0fabbe192f with the rationale is that BHttpRequest auto-redirection might cause the headers to become obsolete by the time a client process the BMessage received from BUrlProtocolDispatchingListener. With the change to BHttpRequest to not notify listeners when auto-redirection is enabled, this is no longer the case and the serialization code can go away now. This simplifies BUrlResult and its subclasses, and gain us some performance for clients using BUrlProtocolDispatchingListener as the result object no longer has to be serialized. This also change the ABI of BUrlProtocolListener::HeadersReceived to no longer passing a BUrlResult. Additionally, BUrlResult and BHttpResult now express the size of the content as an off_t, thus allowing results larger than 4 GB. Change-Id: I9dd29a8b26fdd9aa8e5bbad8d1728084f136312d Reviewed-on: https://review.haiku-os.org/c/haiku/+/3082 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-07-18 06:58:55 +03:00
#endif
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
BHttpResult(const BHttpResult& other);
~BHttpResult();
libbnetapi: fix access to HTTP headers The asynchronous listener had no reliable way to access HTTP result and headers from the callbacks. As the callbacks are triggered asynchronously, they can be run after the request has carried on and, for example, followed an HTTP redirect, clearing its internal state. The HeadersReceived callback now passes a reference to BUrlResult for the request. There are two cases: - Synchronous listener: passes a reference to the request's results directly - Asynchronous listener: archives a copy of the result into the notification message, and passes a reference to the unarchived copy. Unfortunately this comes with several ABI and API breakages: - Change to the prototype of HeadersReceived() - Change to the class hierarchy of BUrlResult (implements BArchivable) All users of HTTP requests will need to be updated if they implemented in HeadersReceived or used BUrlResult.
2017-01-29 21:25:02 +03:00
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
// Result parameters modifications
void SetUrl(const BUrl& url);
libbnetapi: fix access to HTTP headers The asynchronous listener had no reliable way to access HTTP result and headers from the callbacks. As the callbacks are triggered asynchronously, they can be run after the request has carried on and, for example, followed an HTTP redirect, clearing its internal state. The HeadersReceived callback now passes a reference to BUrlResult for the request. There are two cases: - Synchronous listener: passes a reference to the request's results directly - Asynchronous listener: archives a copy of the result into the notification message, and passes a reference to the unarchived copy. Unfortunately this comes with several ABI and API breakages: - Change to the prototype of HeadersReceived() - Change to the class hierarchy of BUrlResult (implements BArchivable) All users of HTTP requests will need to be updated if they implemented in HeadersReceived or used BUrlResult.
2017-01-29 21:25:02 +03:00
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
// Result parameters access
const BUrl& Url() const;
Reintroduce BUrlResult and add BDataRequest * BUrlResult is back, with ContentType and Length methods. * BHttpResult subclasses it and use HTTP header fields to implement those * Introduce BDataRequest for "data" URIs. These embed the data inside the URI, either as plaintext or base64 encoded.
2013-12-09 23:26:13 +04:00
BString ContentType() const;
libbnetservices: BUrlResult is no longer a BArchivable The switch to make BUrlResult serializable was debuted in f9e1854f198d4200f21a9cbe29fdfb0fabbe192f with the rationale is that BHttpRequest auto-redirection might cause the headers to become obsolete by the time a client process the BMessage received from BUrlProtocolDispatchingListener. With the change to BHttpRequest to not notify listeners when auto-redirection is enabled, this is no longer the case and the serialization code can go away now. This simplifies BUrlResult and its subclasses, and gain us some performance for clients using BUrlProtocolDispatchingListener as the result object no longer has to be serialized. This also change the ABI of BUrlProtocolListener::HeadersReceived to no longer passing a BUrlResult. Additionally, BUrlResult and BHttpResult now express the size of the content as an off_t, thus allowing results larger than 4 GB. Change-Id: I9dd29a8b26fdd9aa8e5bbad8d1728084f136312d Reviewed-on: https://review.haiku-os.org/c/haiku/+/3082 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-07-18 06:58:55 +03:00
#ifdef LIBNETAPI_DEPRECATED
Reintroduce BUrlResult and add BDataRequest * BUrlResult is back, with ContentType and Length methods. * BHttpResult subclasses it and use HTTP header fields to implement those * Introduce BDataRequest for "data" URIs. These embed the data inside the URI, either as plaintext or base64 encoded.
2013-12-09 23:26:13 +04:00
size_t Length() const;
libbnetservices: BUrlResult is no longer a BArchivable The switch to make BUrlResult serializable was debuted in f9e1854f198d4200f21a9cbe29fdfb0fabbe192f with the rationale is that BHttpRequest auto-redirection might cause the headers to become obsolete by the time a client process the BMessage received from BUrlProtocolDispatchingListener. With the change to BHttpRequest to not notify listeners when auto-redirection is enabled, this is no longer the case and the serialization code can go away now. This simplifies BUrlResult and its subclasses, and gain us some performance for clients using BUrlProtocolDispatchingListener as the result object no longer has to be serialized. This also change the ABI of BUrlProtocolListener::HeadersReceived to no longer passing a BUrlResult. Additionally, BUrlResult and BHttpResult now express the size of the content as an off_t, thus allowing results larger than 4 GB. Change-Id: I9dd29a8b26fdd9aa8e5bbad8d1728084f136312d Reviewed-on: https://review.haiku-os.org/c/haiku/+/3082 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-07-18 06:58:55 +03:00
#else
off_t Length() const;
#endif
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
// HTTP-Specific stuff
const BHttpHeaders& Headers() const;
const BString& StatusText() const;
int32 StatusCode() const;
libbnetapi: fix access to HTTP headers The asynchronous listener had no reliable way to access HTTP result and headers from the callbacks. As the callbacks are triggered asynchronously, they can be run after the request has carried on and, for example, followed an HTTP redirect, clearing its internal state. The HeadersReceived callback now passes a reference to BUrlResult for the request. There are two cases: - Synchronous listener: passes a reference to the request's results directly - Asynchronous listener: archives a copy of the result into the notification message, and passes a reference to the unarchived copy. Unfortunately this comes with several ABI and API breakages: - Change to the prototype of HeadersReceived() - Change to the class hierarchy of BUrlResult (implements BArchivable) All users of HTTP requests will need to be updated if they implemented in HeadersReceived or used BUrlResult.
2017-01-29 21:25:02 +03:00
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
// Result tests
bool HasHeaders() const;
libbnetapi: fix access to HTTP headers The asynchronous listener had no reliable way to access HTTP result and headers from the callbacks. As the callbacks are triggered asynchronously, they can be run after the request has carried on and, for example, followed an HTTP redirect, clearing its internal state. The HeadersReceived callback now passes a reference to BUrlResult for the request. There are two cases: - Synchronous listener: passes a reference to the request's results directly - Asynchronous listener: archives a copy of the result into the notification message, and passes a reference to the unarchived copy. Unfortunately this comes with several ABI and API breakages: - Change to the prototype of HeadersReceived() - Change to the class hierarchy of BUrlResult (implements BArchivable) All users of HTTP requests will need to be updated if they implemented in HeadersReceived or used BUrlResult.
2017-01-29 21:25:02 +03:00
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
// Overloaded members
libbnetapi: fix access to HTTP headers The asynchronous listener had no reliable way to access HTTP result and headers from the callbacks. As the callbacks are triggered asynchronously, they can be run after the request has carried on and, for example, followed an HTTP redirect, clearing its internal state. The HeadersReceived callback now passes a reference to BUrlResult for the request. There are two cases: - Synchronous listener: passes a reference to the request's results directly - Asynchronous listener: archives a copy of the result into the notification message, and passes a reference to the unarchived copy. Unfortunately this comes with several ABI and API breakages: - Change to the prototype of HeadersReceived() - Change to the class hierarchy of BUrlResult (implements BArchivable) All users of HTTP requests will need to be updated if they implemented in HeadersReceived or used BUrlResult.
2017-01-29 21:25:02 +03:00
BHttpResult& operator=(const BHttpResult& other);
libbnetservices: BUrlResult is no longer a BArchivable The switch to make BUrlResult serializable was debuted in f9e1854f198d4200f21a9cbe29fdfb0fabbe192f with the rationale is that BHttpRequest auto-redirection might cause the headers to become obsolete by the time a client process the BMessage received from BUrlProtocolDispatchingListener. With the change to BHttpRequest to not notify listeners when auto-redirection is enabled, this is no longer the case and the serialization code can go away now. This simplifies BUrlResult and its subclasses, and gain us some performance for clients using BUrlProtocolDispatchingListener as the result object no longer has to be serialized. This also change the ABI of BUrlProtocolListener::HeadersReceived to no longer passing a BUrlResult. Additionally, BUrlResult and BHttpResult now express the size of the content as an off_t, thus allowing results larger than 4 GB. Change-Id: I9dd29a8b26fdd9aa8e5bbad8d1728084f136312d Reviewed-on: https://review.haiku-os.org/c/haiku/+/3082 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-07-18 06:58:55 +03:00
#ifdef LIBNETAPI_DEPRECATED
libbnetapi: fix access to HTTP headers The asynchronous listener had no reliable way to access HTTP result and headers from the callbacks. As the callbacks are triggered asynchronously, they can be run after the request has carried on and, for example, followed an HTTP redirect, clearing its internal state. The HeadersReceived callback now passes a reference to BUrlResult for the request. There are two cases: - Synchronous listener: passes a reference to the request's results directly - Asynchronous listener: archives a copy of the result into the notification message, and passes a reference to the unarchived copy. Unfortunately this comes with several ABI and API breakages: - Change to the prototype of HeadersReceived() - Change to the class hierarchy of BUrlResult (implements BArchivable) All users of HTTP requests will need to be updated if they implemented in HeadersReceived or used BUrlResult.
2017-01-29 21:25:02 +03:00
virtual status_t Archive(BMessage*, bool) const;
static BArchivable* Instantiate(BMessage*);
libbnetservices: BUrlResult is no longer a BArchivable The switch to make BUrlResult serializable was debuted in f9e1854f198d4200f21a9cbe29fdfb0fabbe192f with the rationale is that BHttpRequest auto-redirection might cause the headers to become obsolete by the time a client process the BMessage received from BUrlProtocolDispatchingListener. With the change to BHttpRequest to not notify listeners when auto-redirection is enabled, this is no longer the case and the serialization code can go away now. This simplifies BUrlResult and its subclasses, and gain us some performance for clients using BUrlProtocolDispatchingListener as the result object no longer has to be serialized. This also change the ABI of BUrlProtocolListener::HeadersReceived to no longer passing a BUrlResult. Additionally, BUrlResult and BHttpResult now express the size of the content as an off_t, thus allowing results larger than 4 GB. Change-Id: I9dd29a8b26fdd9aa8e5bbad8d1728084f136312d Reviewed-on: https://review.haiku-os.org/c/haiku/+/3082 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-07-18 06:58:55 +03:00
#endif
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
private:
BUrl fUrl;
libbnetservices: BUrlResult is no longer a BArchivable The switch to make BUrlResult serializable was debuted in f9e1854f198d4200f21a9cbe29fdfb0fabbe192f with the rationale is that BHttpRequest auto-redirection might cause the headers to become obsolete by the time a client process the BMessage received from BUrlProtocolDispatchingListener. With the change to BHttpRequest to not notify listeners when auto-redirection is enabled, this is no longer the case and the serialization code can go away now. This simplifies BUrlResult and its subclasses, and gain us some performance for clients using BUrlProtocolDispatchingListener as the result object no longer has to be serialized. This also change the ABI of BUrlProtocolListener::HeadersReceived to no longer passing a BUrlResult. Additionally, BUrlResult and BHttpResult now express the size of the content as an off_t, thus allowing results larger than 4 GB. Change-Id: I9dd29a8b26fdd9aa8e5bbad8d1728084f136312d Reviewed-on: https://review.haiku-os.org/c/haiku/+/3082 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-07-18 06:58:55 +03:00
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
BHttpHeaders fHeaders;
int32 fStatusCode;
BString fStatusString;
};
libnetservices.a: Put the experimental API into BPrivate::Network namespace In order to prevent classes between libnetapi.so with the legacy API and applications using the libnetservices.a library, the latter will have the classes in a distinct namespace. In the implementation, both libbnetapi.so and libnetservices.a will use the same header and source files. If LIBNETAPI_DEPRECATED is defined during build, the headers and source will have binary compatible behavior. Otherwise, the classes and other objects will be put in the HaikuExt namespace. In order to build the libbnetapi.so and libnetservices.a with the proper build configuration, there is a stub `src/kits/net/libnetapi_deprecated` folder that applies the special configuration to the source files. Currently HaikuDepot, Webpositive, libshared.a and the http_streamer add on use the compatible API in libbnetapi.so. Change-Id: Ic73e9f271ef75749adda46f6f72e9a0b2851b461 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3667 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2021-01-22 17:20:19 +03:00
#ifndef LIBNETAPI_DEPRECATED
} // namespace Network
} // namespace BPrivate
#endif
Move UrlResult to HttpResult * Remove the fRawData field, as handling it is too complicated (it's not easy to have proper copy semantics on a BDataIO) and it's not used anyway, as the listener DataReceived call is enough to get the data and handle it. * All the remaining fields are HTTP-only, so rename the class to HttpResult and attach it to HttpRequest instead of UrlRequest.
2013-10-24 19:26:17 +04:00
#endif // _B_URL_RESULT_H_
Reference in New Issue Copy Permalink