haiku/headers/private/netservices/NetworkCookieJar.h

172 lines
3.9 KiB
C
Raw Normal View History

/*
* Copyright 2010-2013 Haiku Inc. All rights reserved.
* Distributed under the terms of the MIT License.
*/
#ifndef _B_NETWORK_COOKIE_JAR_H_
#define _B_NETWORK_COOKIE_JAR_H_
First steps towards cookie jar thread-safety * Change the semantics of the iterators copy constructor and assignment operator: they now return a new iterator for the same cookie jar (and same url for the UrlIterator). They don't try to point to the same position as the copied iterator. The only purpose of these is to write code such as: Iterator it = jar.GetIterator(); so having a full copy isn't that useful. * The per-domain cookie lists are now protected with a read-write lock. The iterators retain a read lock while they are handling cookies from that list. They get a write lock when doing Remove. Adding a cookie to the jar also gets the write lock for the matching list * Fix a memory leak when adding a new domain-list to the jar failed * Simplify the declaration of the PrivateHashMap type (it would be even simpler if HashMap was a public API) * The domain hashmap is now a SynchronizedHashMap. It is locked as long as an Iterator or UrlIterator exists, which may be a problem as these are public APIs. Writing safe iterators for an hashmap with concurrent accesses is not easy, so the API could be modified to return a list of domains and a list of cookies for a given domain or URL instead. This would suit the intended uses just as well. * The jar now store const cookies, so there is no need to lock them for access/modification. Updating a cookie is done by replacing it with another one in the jar (with the same domain and value). There is still the problem of deleting a cookie while other threads may still access it, this will be fixed by making cookies BReferenceable.
2014-06-11 12:52:11 +04:00
#include <pthread.h>
#include <Archivable.h>
#include <Flattenable.h>
#include <Message.h>
#include <NetworkCookie.h>
First steps towards cookie jar thread-safety * Change the semantics of the iterators copy constructor and assignment operator: they now return a new iterator for the same cookie jar (and same url for the UrlIterator). They don't try to point to the same position as the copied iterator. The only purpose of these is to write code such as: Iterator it = jar.GetIterator(); so having a full copy isn't that useful. * The per-domain cookie lists are now protected with a read-write lock. The iterators retain a read lock while they are handling cookies from that list. They get a write lock when doing Remove. Adding a cookie to the jar also gets the write lock for the matching list * Fix a memory leak when adding a new domain-list to the jar failed * Simplify the declaration of the PrivateHashMap type (it would be even simpler if HashMap was a public API) * The domain hashmap is now a SynchronizedHashMap. It is locked as long as an Iterator or UrlIterator exists, which may be a problem as these are public APIs. Writing safe iterators for an hashmap with concurrent accesses is not easy, so the API could be modified to return a list of domains and a list of cookies for a given domain or URL instead. This would suit the intended uses just as well. * The jar now store const cookies, so there is no need to lock them for access/modification. Updating a cookie is done by replacing it with another one in the jar (with the same domain and value). There is still the problem of deleting a cookie while other threads may still access it, this will be fixed by making cookies BReferenceable.
2014-06-11 12:52:11 +04:00
#include <ObjectList.h>
#include <String.h>
#include <Url.h>
namespace BPrivate {
namespace Network {
First steps towards cookie jar thread-safety * Change the semantics of the iterators copy constructor and assignment operator: they now return a new iterator for the same cookie jar (and same url for the UrlIterator). They don't try to point to the same position as the copied iterator. The only purpose of these is to write code such as: Iterator it = jar.GetIterator(); so having a full copy isn't that useful. * The per-domain cookie lists are now protected with a read-write lock. The iterators retain a read lock while they are handling cookies from that list. They get a write lock when doing Remove. Adding a cookie to the jar also gets the write lock for the matching list * Fix a memory leak when adding a new domain-list to the jar failed * Simplify the declaration of the PrivateHashMap type (it would be even simpler if HashMap was a public API) * The domain hashmap is now a SynchronizedHashMap. It is locked as long as an Iterator or UrlIterator exists, which may be a problem as these are public APIs. Writing safe iterators for an hashmap with concurrent accesses is not easy, so the API could be modified to return a list of domains and a list of cookies for a given domain or URL instead. This would suit the intended uses just as well. * The jar now store const cookies, so there is no need to lock them for access/modification. Updating a cookie is done by replacing it with another one in the jar (with the same domain and value). There is still the problem of deleting a cookie while other threads may still access it, this will be fixed by making cookies BReferenceable.
2014-06-11 12:52:11 +04:00
class BNetworkCookieList: public BObjectList<const BNetworkCookie> {
public:
BNetworkCookieList();
~BNetworkCookieList();
status_t LockForReading();
status_t LockForWriting();
status_t Unlock();
private:
pthread_rwlock_t fLock;
};
class BNetworkCookieJar : public BArchivable, public BFlattenable {
public:
// Nested types
class Iterator;
class UrlIterator;
struct PrivateIterator;
struct PrivateHashMap;
public:
BNetworkCookieJar();
BNetworkCookieJar(
const BNetworkCookieJar& other);
BNetworkCookieJar(
const BNetworkCookieList& otherList);
BNetworkCookieJar(BMessage* archive);
virtual ~BNetworkCookieJar();
status_t AddCookie(const BNetworkCookie& cookie);
status_t AddCookie(const BString& cookie,
const BUrl& url);
status_t AddCookie(BNetworkCookie* cookie);
status_t AddCookies(const BNetworkCookieList& cookies);
uint32 DeleteOutdatedCookies();
uint32 PurgeForExit();
// BArchivable members
virtual status_t Archive(BMessage* into,
bool deep = true) const;
static BArchivable* Instantiate(BMessage* archive);
// BFlattenable members
virtual bool IsFixedSize() const;
virtual type_code TypeCode() const;
virtual ssize_t FlattenedSize() const;
virtual status_t Flatten(void* buffer, ssize_t size)
const;
virtual bool AllowsTypeCode(type_code code) const;
virtual status_t Unflatten(type_code code,
const void* buffer, ssize_t size);
BNetworkCookieJar& operator=(const BNetworkCookieJar& other);
// Iterators
Iterator GetIterator() const;
UrlIterator GetUrlIterator(const BUrl& url) const;
private:
void _DoFlatten() const;
private:
friend class Iterator;
friend class UrlIterator;
PrivateHashMap* fCookieHashMap;
mutable BString fFlattened;
};
class BNetworkCookieJar::Iterator {
public:
2014-06-11 21:27:03 +04:00
Iterator(const Iterator& other);
~Iterator();
First steps towards cookie jar thread-safety * Change the semantics of the iterators copy constructor and assignment operator: they now return a new iterator for the same cookie jar (and same url for the UrlIterator). They don't try to point to the same position as the copied iterator. The only purpose of these is to write code such as: Iterator it = jar.GetIterator(); so having a full copy isn't that useful. * The per-domain cookie lists are now protected with a read-write lock. The iterators retain a read lock while they are handling cookies from that list. They get a write lock when doing Remove. Adding a cookie to the jar also gets the write lock for the matching list * Fix a memory leak when adding a new domain-list to the jar failed * Simplify the declaration of the PrivateHashMap type (it would be even simpler if HashMap was a public API) * The domain hashmap is now a SynchronizedHashMap. It is locked as long as an Iterator or UrlIterator exists, which may be a problem as these are public APIs. Writing safe iterators for an hashmap with concurrent accesses is not easy, so the API could be modified to return a list of domains and a list of cookies for a given domain or URL instead. This would suit the intended uses just as well. * The jar now store const cookies, so there is no need to lock them for access/modification. Updating a cookie is done by replacing it with another one in the jar (with the same domain and value). There is still the problem of deleting a cookie while other threads may still access it, this will be fixed by making cookies BReferenceable.
2014-06-11 12:52:11 +04:00
Iterator& operator=(const Iterator& other);
bool HasNext() const;
First steps towards cookie jar thread-safety * Change the semantics of the iterators copy constructor and assignment operator: they now return a new iterator for the same cookie jar (and same url for the UrlIterator). They don't try to point to the same position as the copied iterator. The only purpose of these is to write code such as: Iterator it = jar.GetIterator(); so having a full copy isn't that useful. * The per-domain cookie lists are now protected with a read-write lock. The iterators retain a read lock while they are handling cookies from that list. They get a write lock when doing Remove. Adding a cookie to the jar also gets the write lock for the matching list * Fix a memory leak when adding a new domain-list to the jar failed * Simplify the declaration of the PrivateHashMap type (it would be even simpler if HashMap was a public API) * The domain hashmap is now a SynchronizedHashMap. It is locked as long as an Iterator or UrlIterator exists, which may be a problem as these are public APIs. Writing safe iterators for an hashmap with concurrent accesses is not easy, so the API could be modified to return a list of domains and a list of cookies for a given domain or URL instead. This would suit the intended uses just as well. * The jar now store const cookies, so there is no need to lock them for access/modification. Updating a cookie is done by replacing it with another one in the jar (with the same domain and value). There is still the problem of deleting a cookie while other threads may still access it, this will be fixed by making cookies BReferenceable.
2014-06-11 12:52:11 +04:00
const BNetworkCookie* Next();
const BNetworkCookie* NextDomain();
const BNetworkCookie* Remove();
void RemoveDomain();
private:
2014-06-11 21:27:03 +04:00
Iterator(const BNetworkCookieJar* map);
void _FindNext();
private:
friend class BNetworkCookieJar;
BNetworkCookieJar* fCookieJar;
PrivateIterator* fIterator;
BNetworkCookieList* fLastList;
BNetworkCookieList* fList;
First steps towards cookie jar thread-safety * Change the semantics of the iterators copy constructor and assignment operator: they now return a new iterator for the same cookie jar (and same url for the UrlIterator). They don't try to point to the same position as the copied iterator. The only purpose of these is to write code such as: Iterator it = jar.GetIterator(); so having a full copy isn't that useful. * The per-domain cookie lists are now protected with a read-write lock. The iterators retain a read lock while they are handling cookies from that list. They get a write lock when doing Remove. Adding a cookie to the jar also gets the write lock for the matching list * Fix a memory leak when adding a new domain-list to the jar failed * Simplify the declaration of the PrivateHashMap type (it would be even simpler if HashMap was a public API) * The domain hashmap is now a SynchronizedHashMap. It is locked as long as an Iterator or UrlIterator exists, which may be a problem as these are public APIs. Writing safe iterators for an hashmap with concurrent accesses is not easy, so the API could be modified to return a list of domains and a list of cookies for a given domain or URL instead. This would suit the intended uses just as well. * The jar now store const cookies, so there is no need to lock them for access/modification. Updating a cookie is done by replacing it with another one in the jar (with the same domain and value). There is still the problem of deleting a cookie while other threads may still access it, this will be fixed by making cookies BReferenceable.
2014-06-11 12:52:11 +04:00
const BNetworkCookie* fElement;
const BNetworkCookie* fLastElement;
int32 fIndex;
};
First steps towards cookie jar thread-safety * Change the semantics of the iterators copy constructor and assignment operator: they now return a new iterator for the same cookie jar (and same url for the UrlIterator). They don't try to point to the same position as the copied iterator. The only purpose of these is to write code such as: Iterator it = jar.GetIterator(); so having a full copy isn't that useful. * The per-domain cookie lists are now protected with a read-write lock. The iterators retain a read lock while they are handling cookies from that list. They get a write lock when doing Remove. Adding a cookie to the jar also gets the write lock for the matching list * Fix a memory leak when adding a new domain-list to the jar failed * Simplify the declaration of the PrivateHashMap type (it would be even simpler if HashMap was a public API) * The domain hashmap is now a SynchronizedHashMap. It is locked as long as an Iterator or UrlIterator exists, which may be a problem as these are public APIs. Writing safe iterators for an hashmap with concurrent accesses is not easy, so the API could be modified to return a list of domains and a list of cookies for a given domain or URL instead. This would suit the intended uses just as well. * The jar now store const cookies, so there is no need to lock them for access/modification. Updating a cookie is done by replacing it with another one in the jar (with the same domain and value). There is still the problem of deleting a cookie while other threads may still access it, this will be fixed by making cookies BReferenceable.
2014-06-11 12:52:11 +04:00
// The copy constructor and assignment operator create new iterators for the
// same cookie jar and url. Iteration will start over.
class BNetworkCookieJar::UrlIterator {
public:
UrlIterator(const UrlIterator& other);
~UrlIterator();
bool HasNext() const;
First steps towards cookie jar thread-safety * Change the semantics of the iterators copy constructor and assignment operator: they now return a new iterator for the same cookie jar (and same url for the UrlIterator). They don't try to point to the same position as the copied iterator. The only purpose of these is to write code such as: Iterator it = jar.GetIterator(); so having a full copy isn't that useful. * The per-domain cookie lists are now protected with a read-write lock. The iterators retain a read lock while they are handling cookies from that list. They get a write lock when doing Remove. Adding a cookie to the jar also gets the write lock for the matching list * Fix a memory leak when adding a new domain-list to the jar failed * Simplify the declaration of the PrivateHashMap type (it would be even simpler if HashMap was a public API) * The domain hashmap is now a SynchronizedHashMap. It is locked as long as an Iterator or UrlIterator exists, which may be a problem as these are public APIs. Writing safe iterators for an hashmap with concurrent accesses is not easy, so the API could be modified to return a list of domains and a list of cookies for a given domain or URL instead. This would suit the intended uses just as well. * The jar now store const cookies, so there is no need to lock them for access/modification. Updating a cookie is done by replacing it with another one in the jar (with the same domain and value). There is still the problem of deleting a cookie while other threads may still access it, this will be fixed by making cookies BReferenceable.
2014-06-11 12:52:11 +04:00
const BNetworkCookie* Next();
const BNetworkCookie* Remove();
UrlIterator& operator=(const UrlIterator& other);
private:
UrlIterator(const BNetworkCookieJar* map,
const BUrl& url);
First steps towards cookie jar thread-safety * Change the semantics of the iterators copy constructor and assignment operator: they now return a new iterator for the same cookie jar (and same url for the UrlIterator). They don't try to point to the same position as the copied iterator. The only purpose of these is to write code such as: Iterator it = jar.GetIterator(); so having a full copy isn't that useful. * The per-domain cookie lists are now protected with a read-write lock. The iterators retain a read lock while they are handling cookies from that list. They get a write lock when doing Remove. Adding a cookie to the jar also gets the write lock for the matching list * Fix a memory leak when adding a new domain-list to the jar failed * Simplify the declaration of the PrivateHashMap type (it would be even simpler if HashMap was a public API) * The domain hashmap is now a SynchronizedHashMap. It is locked as long as an Iterator or UrlIterator exists, which may be a problem as these are public APIs. Writing safe iterators for an hashmap with concurrent accesses is not easy, so the API could be modified to return a list of domains and a list of cookies for a given domain or URL instead. This would suit the intended uses just as well. * The jar now store const cookies, so there is no need to lock them for access/modification. Updating a cookie is done by replacing it with another one in the jar (with the same domain and value). There is still the problem of deleting a cookie while other threads may still access it, this will be fixed by making cookies BReferenceable.
2014-06-11 12:52:11 +04:00
void _Initialize();
bool _SuperDomain();
void _FindNext();
void _FindDomain();
bool _FindPath();
private:
friend class BNetworkCookieJar;
BNetworkCookieJar* fCookieJar;
PrivateIterator* fIterator;
BNetworkCookieList* fList;
BNetworkCookieList* fLastList;
First steps towards cookie jar thread-safety * Change the semantics of the iterators copy constructor and assignment operator: they now return a new iterator for the same cookie jar (and same url for the UrlIterator). They don't try to point to the same position as the copied iterator. The only purpose of these is to write code such as: Iterator it = jar.GetIterator(); so having a full copy isn't that useful. * The per-domain cookie lists are now protected with a read-write lock. The iterators retain a read lock while they are handling cookies from that list. They get a write lock when doing Remove. Adding a cookie to the jar also gets the write lock for the matching list * Fix a memory leak when adding a new domain-list to the jar failed * Simplify the declaration of the PrivateHashMap type (it would be even simpler if HashMap was a public API) * The domain hashmap is now a SynchronizedHashMap. It is locked as long as an Iterator or UrlIterator exists, which may be a problem as these are public APIs. Writing safe iterators for an hashmap with concurrent accesses is not easy, so the API could be modified to return a list of domains and a list of cookies for a given domain or URL instead. This would suit the intended uses just as well. * The jar now store const cookies, so there is no need to lock them for access/modification. Updating a cookie is done by replacing it with another one in the jar (with the same domain and value). There is still the problem of deleting a cookie while other threads may still access it, this will be fixed by making cookies BReferenceable.
2014-06-11 12:52:11 +04:00
const BNetworkCookie* fElement;
const BNetworkCookie* fLastElement;
int32 fIndex;
int32 fLastIndex;
BUrl fUrl;
};
} // namespace Network
} // namespace BPrivate
#endif // _B_NETWORK_COOKIE_JAR_